I've been asked to explain what encapsulation is and I replied "bundling of data and functions that modify this data, is called encapsulation."
The answer was followed by another question—"So, by your definition if I modify a global variable from a member function of a class then the encapsulation is violated."
It made sense to answer YES.
I am not sure whether my explanation is wrong or following question is valid and my answer to it as YES is correct.
Can somebody help.
Quoting from wikipedia:
In programming languages, encapsulation is used to refer to one of two
related but distinct notions, and sometimes to the combination
thereof:
A language mechanism for restricting access to some of the object's components.
A language construct that facilitates the bundling of data with the methods (or other functions) operating on that data
In my humble opinion the answer to the follow up question is subjective and it depends on the interpretation of the notion of encapsulation.
For example it's not a violation if the encapsulating data are limited to be the member variables of classes. A global variable that doesn't belong to an object is accessible by everyone and thus, accessing it via a member function doesn't consist any encapsulation violation.
On the other hand if you consider that encapsulation should be applied to your entire program then this global variable should have been bundled to an object and thus, raw access to it constitutes an encapsulation violation.
The bottom line is that the answer lies in the realms of theology, meaning that it depends on how encapsulation is interpreted by the different programming dogmas.
This depends on how global variable defined and accessed.
Imagine header file containing declaration, but not definitions of member functions, and corresponding implementation file containing class members implementation.
Now consider global variable defined in this header file as internal linkage one (static). Or placed in unnamed namespace. It is a global variable, but functionally it does not differ from private static class member.
It is smelly code, but, I say, that variable is encapsulated properly:
Related
If it's an ordinary local object, its scope begins when it's declared, and things before its declaration can't access it. However, if it's a member variable, then anything in this class, even written before the declaration of that member, has access to it.
What happens under the hood? Why is it designed this way?
I tried to google about it but only got the rule itself instead of the mechanism or the motive.
There's nothing to answer here. It is just that way.
Under the hood happens that the compiler tracks the scope as specified by the language.
Why that language is that way: I'd say it is intuitive, but you seem to disagree, so the only argument I could come up with has been devalued by the very question you're asking. 🤷🏼.
I am confused. In part 3.8 of Bjarne Stroustrup's book 'Programming Principles and Practice Using C++' he talks about types of objects. I cite the following list:
A type defines a set of possible values and a set of operations (for an object).
An object is some memory that holds a value of a given type.
A value is a set of bits in memory interpreted according to a type.
A variable is a named object.
A declaration is a statement that gives a name to an object.
A definition is a declaration that sets aside memory for an object.
From his explanation of definition I understand that no memory is set aside for an object during declaration. However, the fact that Bjarne mentions that declaration involves the naming of an object, suggests that memory is actually set aside, as objects are explained as being
some memory that holds a value of a given type.
Can someone clarify this?
One of the complexities of C++ is that compilation is done in "translation units" (without seeing the whole program). Each translation units contains declarations of some parts defined in other translation units and definitions of some other parts. The declaration provides enough information to be able to generate code that uses the declared part once the address will be resolved by the linker.
Only one definition for an object or non-inline function is allowed in a program but there can be multiple declarations.
Things are indeed even more complex than this because of templates and some magic that C++ can do at link time (e.g. static variables in inline functions).
A declarations says "there is an object/function like this somewhere", a definition says "make an object/function like this".
When reading the book Programming: Principles and Practices using C++, 2nd Edition I came along the following statement:
...what do you do if you really need a global variable (or constant)
with a complicated initializer? A plausible example would be that we
wanted a default value for a Date type we were providing for a library
supporting business transactions:
const Date default_date(1970,1,1); // the default date is January 1, 1970
How would we know that default_date was never used before it was
initialized? Basically, we can’t know, so we shouldn’t write that
definition...
What got me curious about this line of code is the implied idea of using a global variable before its definition. What did the author (Bjarne Stroupstrup) exactly mean by using a global variable before its initialization? Of course, one could have declared the variable somewhere else. But that scenario is not mentioned.
If there's another object declared in global scope, somewhere else, with a complex constructor, you have no practical means to specify the relative initialization order of these two objects in a portable manner. You can't expect, for either object, that the other object has been constructed, before it is referenced.
There's nothing inherently wrong with declaring global singleton objects, where they make sense, as long as it is fully understood that the relative initialization order of global objects in different translation units is not specified.
Can someone please disambiguate class attributes and methods for C++? I was under the impression that attribute means any member variable, and method means any member function.
Thanks
Define "correct".
Referring to data members and member functions as "attributes/properties" and "methods", respectively, is common practice - it's the general OO wording. ("attributes" are used in C++ for something else, though, so this may very well be a source of confusion.)
The C++ standard, however, does not use these terms (apart from attributes of course, as explained above). If you don't want to risk anything and always be correct, use "data members" and "member functions".
But if you only want to explain C++ to a Java programmer, you may get away with "property" and "method" in the beginning.
I would not do that. While it can be understood in the general context of OO, it will be confusing in C++ as attribute has a precise definition in the standard, that is not that of data member.
A class' attributes would translate to its members. A method is not the same as a member function in general. But "In object-oriented programming, a method is a subroutine (or procedure) associated with a class." - Wikipedia.
In common words, an attribute describes something, "One of the attributes of this car is that it's quite long", or "one of the attributes of the giant panda is it's striking black and white colours".
I XML, attributes are used to add extra information in a tag, e.g <species id=3212>Ailuropoda melanoleuca<common_name>Giant Panda</common_name></species> - id is an attribute, Ailuropoda melanoleuca is a value, common_name a tag within species.
But I call the variables in a class "member variables", and functions in a class "member function" or "method".
I have a class and a given quite complicated method for the sake of which I've defined some auxiliary functions, which aren't however used anywhere else. Now I'm wondering whether I should
add them to my class - it seems to be what it should be done according to the OOP paradigm
keep them outside, i.e. separately, only in my implementation file - since filling up my class definition with that sort of semi-redundant methods would make my class definition less readable.
My question is what should I do when C++ style is concerned. I feel that the second solution goes against the OOP principles, though C++ isn't an object-oriented language but a hybrid one. The functions I mention, if implemented as class methods, would be static.
Put them in an Unnamed namespace inside your source file.
The unnamed namespace allows your functions to be visible within the translation unit, but not outside the translation unit. Your functions still have an external linkage but they are simply invisible to anyone outside the translation unit.
FWIW, I'm going to add this: the answers given so far are fine, but since C++11 I found that for strictly auxiliary functions there is a better and less intrusive solution:
Define them as lambdas inside the method they serve.
This will make them invisible everywhere else and give them proper access permissions without requiring the use of a friend declaration or making them private static members.