In addition to public inheritance, C++ also supports three more rarely used forms of derivation;
private,
protected and
virtual.
Public inheritance
class A {};
class B : public A {};Public inheritance models an
is-a relationship (e.g.,
Employee is a
Person). Class members can be inherited or redefined in the derived class. Dynamic polymorphism (
run-time binding) is achieved through the use of
virtual member functions.
class A
{
public:
virtual void stuff() { std::cout << "A::stuff()" << std::endl; }
};
class B : public A
{
public:
void stuff() { std::cout << "B::stuff()" << std::endl; }
};
// ...
A* x = new B;
x->stuff(); // B::stuff()The scope resolution operator (::) can be used to qualify hidden names:
struct A { int x; };
struct B : public A { int x; }; // A::x is now hidden
// in the scope of B
// ...
B b;
b.x = 1; // refers to B::x
b.A::x = 2; // uses the qualified nameComposition
Many times, inheritance introduces strong coupling, and a general rule of OO design is that you should prefer composition over inheritance. Composition, or
containment, expresses the type of relationship where one object of a specific type contains an object of another type. This is also known as a
has-a relationship.
class A
{
public:
void doStuff() { std::cout << "doing stuff!" << std::endl; }
};
class B
{
private:
A m_a; // B has an A
};Friendship
In C++, it is also possible to declare classes
friends of each other. Doing so gives the "befriended" class access to
private and
protected members of the class in which the
friend keyword appears.
class B; // forward declaration
class A
{
private:
void doStuff() { std::cout << "doing stuff!" << std::endl; }
friend class B;
};
class B
{
public:
void doStuffWithA()
{
m_a.doStuff(); // Possible due to friendship
}
private:
A m_a;
};Friendship is a powerful feature that should be used sparingly, and only in cases where classes are closely related. Now, let's take a look at private and protected inheritance, and how they relate to containment.
Private inheritance
class A {};
class B : private A {};Private inheritance results in all
public functions of a class being inherited as
private.
class A
{
public:
void doStuff() { std::cout << "doing stuff!" << std::endl; }
};
class B : private A {};
// ...
B b;
b.doStuff(); // error: ‘void A::doStuff()’ is inaccessibleAs it turns out,
this is very similar to composition, and the
has-a kind of relationship described earlier.
Has-a vs. is-implemented-in-terms-of
Composition can actually signify two different types of relationship, namely
- has-a, and
- is-implemented-in-terms-of.
Scott Meyers explains the difference
in
this interview by Bill Venners. It goes something like this: In software design, and object oriented programming in particular, we are dealing with two separate domains. Objects can be described as either
- real world objects, or
- implementation artifacts.
The former is referred to as the
application domain and the latter as
implementation domain. Classes in the application domain would be, for example,
User,
Calendar,
Document, and
Brush. The implementation domain could include
Mutex,
List,
Array,
Buffer,
SmartPointer etc. Implementation artifacts are abstractions that only make sense in the context of the program itself. A
has-a relationship means the type of composition that corresponds to the application domain, whereas
is-implemented-in-terms-of relates more to the implementation. Perhaps an
Employee has a
Role,
class Role
{
// ...
};
class Employee
{
private:
Role m_role;
};but
Staff is implemented in terms of a
List (of
Employees).
class Staff : private std::list<Employee>
{
// ...
};The distinction is not 100% obvious to me, but … nevertheless, it should be clear that the reason for not using public inheritance here is to avoid the interface of
std::list being exposed through our
Staff class.
Private inheritance is similar to containment, but in the case of containment, the containing class operates only on the public interface of the contained object. Using private inheritance, the derived class can also access
protected members of the base class.
Other differences between (simple) composition and private inheritance are, that:
- Using composition, a class can contain more than one object.
- Using private inheritance, the derived class can override the base class' virtual functions.
Composition gives us control over how, and to what extent, the public interface of a contained object is exposed:
class A
{
public:
void doStuff() {}
};
class B
{
public:
void doStuff()
{
m_a.doStuff();
}
private:
A m_a;
};Private inheritance makes this even more straightforward. The interface of the derived class is inaccessible from the outside world, however, a
using directive can relax the terms of this contract:
class B : private A
{
public:
using A::doStuff;
};When should we use private inheritance then? The
C++ FAQ Lite says:
Use composition when you can, private inheritance when you have to.
Protected inheritance
class A {};
class B : protected A {};Protected inheritance is similar to private, with the difference that the base class'
public functions now are being inherited as
protected instead of
private.
class A
{
public:
void hello() {}
};
class B : private A {};
class C : public B
{
public:
C() { hello(); } // error: ‘void A::hello()’ is inaccessible
};Using private inheritance for class B, class C, derived from B, does not have access to A's
public members, hence the error:
error: ‘void A::hello()’ is inaccessible
On the other hand, if we change the declaration of B to,
class B : protected A {};the program will compile.
Virtual inheritance
Multiple inheritance is a source of much confusion, and usually best avoided. Virtual inheritance exists to address a problem called the
Diamond Problem. This is a situation that arises due to multiple inheritance, when the class structure becomes ambiguous as a result of a class being inherited more than once:
class Base
{
public:
virtual void doStuff() {}
};
class A : public Base {};
class B : public Base {};
class C : public A, public B {};
// ...
C c;
c.doStuff();This produces the following error:
request for member ‘doStuff’ is ambiguous
The problem comes from the fact that both A and B inherit Base, hence
doStuff() could refer to both
A::doStuff() and
B::doStuff(). Looking at the class hierarchy, the diamond shape appears.
This ambiguity can be resolved. One way would be to simply qualify all calls.
c.A::doStuff();
This, however, is usually not the best solution. Instead, we can make
Base a
virtual base class to A and B, and therefore behave as if it was a direct base class of C.
class Base
{
public:
virtual void doStuff() {}
};
class A : virtual public Base {};
class B : virtual public Base {};
class C : public A, public B {};
// ...
C c;
c.doStuff(); // ok!A derived class can have both virtual and non-virtual base classes.
See this article for a more in-depth discussion:
http://www.cprogramming.com/tutorial/virtual_inheritance.html
Entries
