If I'm creating an abstract base class, and the classes derived from it are going to have some of the same data members, is it better practice to make those members private in the abstract base class and give protected access to them? Or to not bother and just put the data members in the derived classes. This is in C++.
The main question to ask in an OOP setting is: Where does this data belong?
In an inheritance relationship, Data (and functionality) should be defined at the highest stage where it is more or less invariant. This promotes maximum modularity and code-reuse. For example, assume two classes:
class Human;
class Student : public Human;
When adding a data member 'm_Arms', we determine the 'Human' level as the best place to define the data, its usage and its visibility to the derived classes, based on the following questions:
Will specializations of humans require more-or-less invariant behavior from the human's arms? i.e. Will they be able to do something that a 'generic' human normally cannot? - (determining common data).
Will the student (or other possible Human specializations) require direct access to it? (determining visibility to child classes).
If visible, which functions are common? (determining associated common functions)
The context should be thought of from the base class's perspective - even if there is one additional is-a-Human class that can do something extra, then it needs to have access to the data. e.g. If for some reason, you decide class Robocop : public Human, you need access to his thigh directly to store the gun inside. Under this architecture, Thigh then needs to become visible to all child classes of Human.
The architecture can be refined using the same principles of data modularity, function modularity and visibility. For example, when defining the class Robocop, The base class Human can be further extracted as follows to allow a change in visibility, and consequent changes in functionality.
class Human;
class NormalHuman : public Human; //declare Thigh private here.
class SuperHuman : public Human; //continue using Thigh as protected.
Further, Arms may themselves be made polymorphic, allowing (excuse the unintended dystopic interpretation) factory-based architectures to modularly assemble different types of Humans using Human parts.
If the data belongs to the derived class, let the derived class do what it wants to contain that data.
By placing that data in the base class (not privately), you force every derived class to have it. The derived classes shouldn't be forced to do anything unless they need to fill out the data member, for example. The base class defines what derived classes must do, not how they should do it.
If you find there might be a common theme, you can make a derived class that has those members and implementations, which is then intended to be the base class for those that want to use it. For example:
struct car
{
virtual ~car(){}
virtual unsigned year(void) const = 0;
virtual const std::string make(void) const = 0;
}
// Dodge cars can feel free to derive from this instead, it's just a helper
struct dodge_car
{
virtual ~car(){}
virtual unsigned year(void) const = 0;
const std::string make(void) const
{
static const std::string result = "Dodge";
return result;
}
}
And so on. But you see, any derived classes still have the choice of implementing the entire car interface. This also improves code cleanliness. By keeping your interface a real interface, implementation details won't get in the way.
Any variables your base class uses should be private, because derived classes don't need to know how it works, in the same way users of your derived class don't need to know how the internals of the derived class work.
How can you make members private and give protected access?
Derived class cannot access base class' private members.
Would Derived class A and Derived class B both need those data members you are talking about? If yes, then put them in base class and make it protected yes.
I know, I actually wanted to post a comment, but I don't know how. May be I need more reputation?
Don't think about what some of your derived classes would do, think about what all of them must do, when writing the base class. In other words, think about the base class itself and the guarantees it makes—its interface.
C++ doesn't have a separate concept of "interface definition" and just reuses classes for that. (Or duck typing in templates.) Because of this, be careful how you write your abstract interface classes so you don't impose restrictions on implementations.
I'm not answering either yes or no because you haven't given enough information, and the answer depends on those other details; but if you follow the guidelines I've briefly laid out, you'll be in decent shape.
There's nothing wrong with having some of the data (and of the implementation, i.e. methods) in the base class.
The base class could be virtual by the mere fact that only one of its methods must be implemented in derived class. The decision of making these variables and methods [of the base class] private, protected or even public, is a case by case issue.
For example the base class could have a public method, a protected method and/or data, and a few private methods.
Related
Musing on a Sunday...
Deriving from a class brings all names from the base class into the scope of the derived class. However, it also adds the base class non-static data members to every instance of the derived class.
Is there a way to achieve the former without the latter? I'm asking in the interest of concise notation.
Obviously, when the base class doesn't have any data members, I get what I want. There are quite a few empty classes or class templates in the standard library defined to do just that - inject names summarily into a class scope through inheritance. There's even the empty base class optimization to make this as cheap as possible.
But if I wanted to do the same with a non-empty base class, I would be tempted to employ something like:
struct Bar {
using struct Foo;
};
But, alas, that's not supported by C++. My question is, is there another way to achieve the same which I overlooked?
To provide a more complete example:
struct Foo {
enum { some_constant=42 };
// data members follow here ...
};
struct Bar {
using class Foo; // this doesn't compile
int f();
};
int Bar::f() {
return some_constant; // I want to use the constant directly, without Foo::
}
One clumsy way could be to split the definitions in Foo into two classes, one with the constants (which would be an empty class I could derive from without penalty) and the other with the data members, but that looks rather like an inelegant hack to me.
If there isn't a clean way to achieve this, maybe someone can provide a rationale for why it doesn't exist, or perhaps shouldn't exist.
Deriving from a class brings all names from the base class into the scope of the derived class.
Let me stop you there. Yes, it is true that inheriting from a base class causes the (non-private) names in the base class to be accessible from the derived class definition. However, that's not why you inherit from a base class; that's merely the mechanism by which inheritance achieves its goal.
To publicly inherit from a base class is to make a statement about the relationship between the derived and base classes. You're saying that every instance of the derived class should behave like the base class in virtually all ways. Even virtual function overriding still carries with it the expectation that the derived class implementations of these methods are conceptually doing the same job, just in a way appropriate for that derived class.
This is true even of mixin-style base classes, where the base class is used to define common functionality that is imported into a particular derived class. In such interfaces, there is little expectation of a user explicitly talking to base class definitions. But this provision of common functionality is ultimately still based on the semantic idea of a derived class being a base class. And that's very important for many of them to do their job.
Consider what is probably the most prominent mixin in the C++ standard library: std::enable_shared_from_this<T>. It has non-static data members, without which it couldn't actually provide the functionality it does (well, it could, but you would have to provide some interface in your derived class to store them, so it may as well do it).
This is true of private inheritance, though there is some modification. While to the outside world, the derived class is just a derived class, to the class definition itself, it still remains a base class. It remains wholly a base class, along with all the baggage that comes along with it.
Do not mistake the mechanism for the meaning. Mechanisms are important; don't get me wrong. But those mechanisms exist to facilitate meaning.
Having a class contain everything of some other class except the non-static data members is, semantically, nonsense. It doesn't mean anything about the relationship between the types. And you've essentially admitted that the main reason you want this is so that you don't have to scope-qualify the names defined in the "base" class.
This is a mechanical reason, not a semantic one. You shouldn't employ a semantic tool like inheritance to escape the mechanical consequences of how you have chosen to design your types.
In reference to your specific example you could make the constants you want to access static, which will allow you to access them from the second class by fully qualifying with the "base" class
In composition, one class explicitly contains the other. However in Inheritance, the base class is implicitly contained in the derived class. Correct or not? I ask this because after several days of studying inheritance, it's only today that I got to read somewhere that an object of a derived class always contains an object of it's base class.
I mean, I thought that there would be only one object and just the functionality would be inherited but I didn't know that it would also contain an object of the base class within.
In Composition, one object contained another object. While in inheritance, your object is acquire properties of base class.
I mean, I thought that there would be only one object and just the
functionality would be inherited but I didn't know that it would also
contain an object of the base class within.
Yes you are right, there will be only one object and functionality is getting inherited. Even if your base class have member variables, there size will getting added to your object size.
You can directly call public and protected methods of base class. While in cointainership you are only able to access public methods.
That's should be:
In composition, one class explicitly contains an object of the other class. However in Inheritance, the base class is implicitly contained in the derived class.
In short:
Composition is about the relationship of class and object.
Inheritance is about the relationship of class and class.
And please remember "Prefer composition over inheritance".
Prefer composition over inheritance?
In general derived class contains all data members and shares the properties/methods of base class, but there is a difference between composition and inheritance.
By "composition" you mean that one object "has" some other object. In example: human has a liver. In class design it can be presented like below:
class Liver {};
class Human
{
public:
Human() {}
private:
Liver mLiver;
}
When talking about an inheritance, there are 2 options: public inheritance roughly says that one object "is" a kind of other object. In example: Human is a kind of living creature. It does not sound naturally to say that human "has" a living creature inside. Public inheritance is a way to go in such case:
class LivingCreature {};
class Human : public LivingCreature
{
public:
Human() {}
}
Other option is protected/private inheritance, which should be used to implement some object "in terms of" other object. Generally it can also be treated as kind of composition, but first approach is usually better.
Summarizing:
If you can say that one object "is" a kind of other, more general object: public inheritance is the best way to go,
If you can say that one object "has" other object: use composition.
Consider the code:
class Engine
{
//Some Code
};
class Vehicle
{
//Some Code
};
class Car:Vehicle
{
Engine engine;
//Some Code
};
In this case class Car inherits the class Vehicle. An object of the class Car doesn't contain an object Vehicle, rather it is an object of the class Vehicle (Inheritance). On the other hand it does contain an object of the class Engine(Composition).
The fact that you can access a parent's function with this comes from the fact that the Car object is a Vehicle not because it contains an Vehicle object.
In composition, one class explicitly contains the other. However in Inheritance, the base class is implicitly contained in the derived class. Correct or not?
It's entirely a matter of knowledge/perspective: if you're aware that inheritance means a base class instance will be embedded in the derived class then saying class Dervived : Base can be seen as explicitly requesting that, while if you're aware that defining a variable inside class X means it's a member variable that will be contained in instances of X, then that can be seen as explicit too.
I ask this because after several days of studying inheritance, it's only today that I got to read somewhere that an object of a derived class always contains an object of it's [sic] base class.
The distinction between actually containing a base class object vs. through some more unspecified/mysterious means being substitutable for a base class instance on occasion, isn't necessarily the most important thing when starting to learn about inheritance, so it's easy to imagine it isn't emphasised in all learning material.
I mean, I thought that there would be only one object and just the functionality would be inherited but I didn't know that it would also contain an object of the base class within.
At an implementation level, it's important that it actually contains a base class instance, so code compiled to handle base class objects can work equally well on derived class instances. The C++ Standard could have deemed it merely an embedded copy of base class content with identical binary layout while not an actual base class object, but then a huge amount of text in the Standard would have to be added to mention that the derived objects could be used in scenarios where a base class instance was acceptable. In other words, the distinction is somewhat arbitrary, but it's easier for everyone if it's both intuitive and lends itself naturally to simpler, more concise Standard wording.
Inheritance vs Composition:: Is my understanding correct?
Conceptual differences:
Inheritance:
In case of inheritance, derived class is sub-type of base class.
Meaning if you derive Dog from Animal, then Dog is Animal and
all* operations that can be performed on Animal can be performed on Dog.
Using private, protected and public inheritance, however, you can control who knows that Dog is Animal and who knows inner workings of Animal. In case of protected or private inheritance only Dog will know that it is Animal, but it won't be obvious from the outside.
Composition:
In case of composition one class is included into another.
a Car is not a Wheel. But it contains Wheel. So operations that work on Wheel will not work on a Car.
By declaring member variable of type Wheel as public, private or protected you can control who can access Car's Wheels.
I believe that is clear enough?
Implementation details:
In case of C++, members of base class are included into derived class. Also methods that existed in base class will be accessible in derived class - somewhere. Access specifiers private, public and protected AND inheritance type determine which methods are visible and where.
I thought that there would be only one object
It is one object.
In microsoft compiler and g++ objects are "merged" together, meaning that in case of:
struct Base{
int a;
};
strict Derived: public Base{
int b;
};
Derived internally will probably (would need to check C++ standard to be sure) have this layout.
strict Derived{
int a;
int c;
};
or
struct Derived{
Base _;
int c;
};
In case of multiple inheritance and diamond inheritance things will get more complicated and base class can be included multiple times.
I've got some confusions on the access level in C++ inheritance and more generally how I should design a C++ class.
class Car
{
public:
private:
string brandName;
}
class Sedan: public Car
{
public:
// this function needs to know the Sedan's brandName
void someFun()
{
brandName = "sss"; // error!!!
}
private:
}
In the above example the Car as a base class has a private member "brandName", and the Sedan as a derived class from Car inherits that member "brandName". As explained in Effective C++, public inheritance makes an "is-a" relationship, which means Sedan is a Car, now can I say that Sedan has a "brandName"?. If the answer is yes, why couldn't Sedan access to its own attribute in someFun?
I know the solution is to change brandName's access level to protected, my confusion is that what features or conditions make a variable member to which access level, in other word how I decide which access level should a given member be attached to?
I'd also like it if you'd recommend any book or article elaborating on this topic.
now can I say that Sedan has a "brandName"?
No, neither has Car. The brandName is an implementatin detail, private, hidden from anyone else and does not contribute to the class' public interface, which is what makes the nature of a Car. So while technically there is a brandName somewhere in a Car and thus in a Sedan, from a pure OO view that does not matter. Similar to "Is-A"-relationships that are expressed only by public inheritance and not by private inheritance, "Has-A"-relationships in the OO point of view are only present if the composition or assoctiation is publicly accessible/visible (mostly via getters/setters).
juanchopanza's answer and the comments to it have lead me to sneak a little around the web, trying to find resources about Is-A and Has-An relationships. this transcription seems to indicate that the two terms did not originate from OO thoughts. In fact, OO literature seems to cite the Liskov Substitution Principle instead of using "Is-A" relationships. It lays stress on encapsulation and opaque objects, so it concerns mostly with public interfaces of classes and how their behavior affect associated objects. While a "Has-A" relationship can be association, it also can be aggregation. In this case, since the brandName is not an external, associated object (in C++ we would express that fact with a pointer or reference member), it is an aggregation-"Has-A", hidden in the opaque Car and therefore not of interest for OO (and the above answer is left semantically valid).
I know the solution is to change brandName's access level to protected
NO! brandName's access level has to remain private, so that Car has the complete control over what happens to it. If you want to access it in derived classes, provide protected getters and/or setters.
I'd also like it if you'd recommend any book or article elaborating on this topic.
Any book about object oriented design should do. If you read through two or more of them, you will get a good idea of what to do and what not to do.
can I say that Sedan has a "brandName"?.
Yes, it certainly has an object of type string called Car::brandName (whether this constitutes an OOP "has-a" relationship isn't entirely clear to me, but probably not: see comments)
If the answer is yes, why couldn't Sedan access to its own attribute in someFun?
Simple because brandName is private. Those are the rules of the language. If you want to give a derived class access to a non-public data member, you can make it protected.
I'd also like it if you'd recommend any book or article elaborating on this topic.
There is a list of books here. Perhaps "The C++ Programming Language" would be good for explaining this particular aspect.
you have hidder brandName from the outer world, by making it private. Make it protected so that children may inherit it. To understand inheritance rules regarding specifiers, go to HERE
Public members are free to all to use.
Private members are for the use of only this current class, and no one else. It is used mostly for inner members of the class to use and save for it's own purposes or to provide a method to access to them.
Protected members are accessible for inherited classes, just as your example shows - brandName is for the use of inherit classes, so it should be protected.
I've got some confusions on the access level in C++ inheritance and more generally how I should design a C++ class.
C++ has three access level specifiers that can be used when inheriting:
private, protected and public
class Derived : public Base
Is called public inheritance and represents IsA relationship. When inheriting publicly, public members of the base remain public in Derived, protected members remain protected in Derived and private members are private (and not accessible from Derived).
class Derived : protected Base
Is called protected inheritance. This kind of inheritance is rare, and would be used if you don't want to expose the public part of Base when accessed as derived (or through the interface of Derived). In this kind of inheritance the public members in base become protected in derived.
Also see the C++ FAQs
class Derived : private Base
Is called private inheritance. This kind of inheritance can be used to simulate containment (Herb Sutter - Uses and abuses of inheritance). Here public members in Base become private when accessed through the interface of derived.
It can also be noted that protected and private inheritance does not represent the classic IsA relationship. The following polymorphic behaviour is only possible when inheriting publicly:
Derived d;
Base* b = &d;
However, for private inheritance polymorphic behaviour is possible in the first derived class (but not in subsequent).
struct Base{};
struct Derived : private Base
{
Derived()
{
//IsA holds within member functions of Derived, but not
// outside
Base* b = this;
}
};
struct Derived2 : public Derived
{
Derived2()
{
Base* b = this; //Fails to compile...inaccessible base
}
};
int main()
{
Derived d;
Base* b = &d; //Fails to compile
}
For protected inheritance polymorphic behaviour is possible in the all subsequent derived classes (Therefore code in constructor of Derived2 here above would compile), but not outside of class member functions.
Herb Sutter comments on reasons for using non public inheritance in Uses and abuses.
Finally, a comment concerning your example above: Usually Car would be abstract (an interface, consisting only of pure virtual functions), and therefore it would not contain any data members, but leave it open to the implementation. This is a guideline concerning inheritance that I've heard somewhere Sutter - Exceptional C++:
Inherit publicly in order to be reused by code that uses base classes polymorphically.
Your example would/could become:
struct Car
{
//Note: const used as brandName should not modify logical state.
virtual const std::string& brandName() const = 0;
//...virtual ~Car(), amongst others, depending
// on whether you intend to be deleted via this interface...
};
// Note: public inheritance implied by struct
struct CarFromFile: /*public*/ Car
{
CarFromFile( std::ifstream& file )
: brandName_( strFrom( file ) ),
manufacturer_( strFrom( file )
{
}
virtual const std::string& brandName() const{ return brandName_; }
private:
std::string strFrom( std::ifstream& file )
{
std::string value;
if( file >> value ) { return value; }
throw std::runtime_error( "Invalid file format!" );
}
std::string brandName_;
std::string manufacturer_;
//etc...
};
The fact that you make the accessor abstract, allows freedom from
the perspective of the implementer of derived, and defines the service
required by the client of base, independent of how the actual data looks.
The classifications for public, protected and private are intended to allow one to separate publicly available interfaces from internal implementation details. Thus, things that are not public are inaccessible, forcing users of the class to use the public interfaces provided.
If something is private, then even though inheritance will make the member a part of the derived class, the derivation is not allowed to access it. If it is desirable to allow a derived class access to interfaces and members that are not part of the public interface, then that is exactly when to use protected.
Well there is enough information about this subject. For example this thread was very clear to me: Difference between private, public, and protected inheritance
Except one point; Why is it useful?
Use public inheritance to reflect an is-a relationship. This is the main use for inheritance, especially in combination with virtual functions. It allows re-use of interface, not just of old code by new code, but also re-use of new code by old code! (because of virtual function dispatch at runtime).
In exceptional circumstances, use private inheritance to reflect an is-implemented-in-terms-of relationship. This is a commonly overused pattern, often the equivalent goal can be reached through composition (having the would-be base class as a data member). Another drawback is that you can easily have multiple inheritance of the same base class (twice or more removed) leading to the so-called Diamond Problem.
Avoid using protected inheritance, it suggest that your class interface is client-dependent (derived classes versus the world). Often this is due to classes having multiple responsiblities, suggesting a refactoring into separate classes is appropriate.
The answer to this question concerns class interfaces and data encapsulation, rather than language capabilities.
The use cases of protected and private inheritance are rather limited, since there are often other options available which better solve the problem (such as using composition, rather than inheritance). However, there are times when you necessarily must inherit from some type (for example to interface with a third-party library), but you would strongly prefer (for reasons related to user interface of your class) to hide most members inherited from the base class from the users of your new type. A typical scenario would be when you need your type to have the member functions of a certain class for internal use, but it would break the logic of your new type if it was called from outside the class itself.
In these situations, you need to use private or protectedinheritance (depending on whether the interface should be similarly restricted to further derived classes or not.
Bear in mind, however, that this is all just about (strongly) hinting to the users of your class how they should use it. You're adapting its public interface to hide certain features which were public in its base class. This doesn't strictly speaking prevent people from accessing these members, since anyone can still cast a pointer to your derived class to a pointer to the base, and reach the "hidden" resources that way.
It's all about Data Encapsulation.
http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming)
Encapsulation concept
It is good to protect your classes 'internal' data from other classes. Benefits include:
other classes have to go through the known proper access mechanisms (e.g. methods) to access your class and can't monkey around with the internals of your class directly (and hence potentially put your class into some unknown and broken state)
you can change the inner workings of your class and know that other classes won't break as a result
reducing visible external points of contact with a class makes your classes simpler to use and understand
Having the option of using protected instead of private also makes your code easier to extend through subclassing.
Private: private members of a class can be accessed only from class functions, constructors, and destructors. The client who will use your class will be unable to access them. So, if for example you are implementing a list class and you want to keep track of the list's size, then you should have a private variable (listSizeP for example). You do this because you don't want the client to be able to modify the size of the list without inserting elements.
Public: public members can also be accessed by the client. In the list example mentioned above, functions like insert and erase should be public.
Protected: protected members of a class, like private members, can be accessed only from class functions, but they can also be accessed by classes inherited by this class(actually it depends on the way the derived class inherits the base. If it is not public inheritance, then the derived class cannot access the private members of the base class. That's why the most common way of inheriting is public inheritance). Example:
#include <iostream>
using namespace std;
class Base {
public:
int num;
public:
Base(int x=0) : num(x) {}
};
class Derived : public Base {
public:
Derived(int x=0) : Base(x) {}
void tell() { cout << "num: " << num << endl; }
};
int main() {
Derived D(4);
D.tell(); // would cause error if num was private
return 0;
}
Bjarne Stroustrup once said that he can address most of the tasks with ONLY private or public member variables and he seldom uses protected member variables in his design. I have heard similar arguments in other places. Here is an example,
class BaseClass
{
...
private:
int m_iAge;
double m_dSalary;
string m_strName;
bool m_bGender;
}
class SubClass : public BaseClass
{
...
}
Given the above class design, how the subclass SubClass can use the variables defined in BaseClass?
Question1> Why we should prefer to having private rather than protected variables? Is it the reason that the BaseClass can hide the implementation detail and make it easy for further improvement?
Question2> In order to let the SubClass access the variable defined in BaseClass, it seems to me that we have to define public access(get/set). However, getter/setter are evil! So the second choice is to define protected access(get/set). Any better idea?
Thank you
Bjarne's point is that generally the derived class shouldn't access the variables of the base class -- doing so frequently leads to maintenance problems. And no, changing it to use get/set (accessor/mutator) functions isn't an improvement.
Ask yourself - why would the derived class ever change the value of m_bGender? Or m_iAge? Doesn't the base class already handle these values correctly?
See, there is generally no need to have direct access to the internals of the base class. So we make them private, and use the class' public interface.
In some very rare cases, there might also be one or two protected functions, if derived classes need some special interface. But that is unusual. If derived classes have different behaviour, we more often use virtual functions for that.
I think the rationale for this claim is that in many situations, subclassing doesn't often change the behavior of the existing (inherited fields), but rather one adds fields and adds new methods that manipulate the new fields.
If you are looking for a way to manipulate inherited members w/o protected, you can, in the base class, make the derived class a friend. You would have to know it ahead of time, though.
The only main reason to use private over protected members is if they indeed are not required in child implementations. That's why we have protected members, because there are cases where the child class does need direct access to members of a parent class. I think Stroustrup is referring to a design whereby there is little need to access parent members in the first place, and child classes simply build upon the functionality of their parent rather than modify the functionality of their parent.
However, getter/setter are evil!
Why so? Getters and setters are an important part of OOP from my experience. There are good reasons to make an interface with a class, rather than access its variables directly.