In C++ you have three kind of inheritance: public, protected and private. From a technical point of view, they differ in the visibility of methods of the derived class and therefore they influence the interface of the derived class. So, from technical point of view these inheritance types are easy to explain. But from a software design point of view, it may become more difficult to explain the different concepts. Within this article I want to give a short overview about these three inheritance types from a software design point of view and connect them with the underlying concepts of the object-oriented paradigm.

Public inheritance

This type of inheritance creates an “is-a” relationship between objects. The derived object will offer the base class interface and therefore the derived class type “is-a” base class type too. This reflects the ideas of inheritance within the object-oriented paradigm. Within a previous article you will find some more details about this concept.

Private inheritance

In contrast to public inheritance, which creates a logical relationship between classes, the private inheritance reflects a more technical point of view. It will create a “is implemented in terms of” relationship between classes. Therefore, this concept competes with composition, which creates the same kind of binding between classes. As your always should prefer composition over inheritance, private inheritance is only needed in case technical limitations omit the use of composition. Within a previous article you will find further information about this concept and some use cases for private inheritance.

Protected inheritance

From a technical point of view, protected inheritance is easy to understand. But from a software design point of view you will get in trouble very quickly. If you think about possible use cases you may come to the decision that public inheritance isn’t needed at all. But C++ offers this feature, as it makes sense from a technical point of view.

The reason for protected inheritance are the same as they for private inheritance. If you have reasons to inherit something privately and additional you want to make functionality accessible to derived classes, you have to use protected inheritance. Obviously, private inheritance should be used scarcely, and protected inheritance even more so. Private inheritance is some kind of a compromise solution were you intentionally violate against some base software design rules, due to technical limitations. Strictly speaking, with protected inheritance you will inherit these design violations from base class to derived class. From a software design point of view, you should never use protected inheritance. And in my opinion the same is true from a technical point of view. The technical limitations can be resolved by using private inheritance. Therefore, I don’t see any reason or any use case for protected inheritance.

Summary

As there are three access levels in C++, it makes sense, from a technical point of view, to provide these access levels for inheritance too. But from a software design point of view you need public inheritance only. Therefore, you should use private inheritance only if you have to deal with situations were technical limitations force you to do so. As these rare situations can be resolved with private inheritance, there is no need for protected inheritance at all.