C++ why use public, private or protected inheritan

Question

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?

Answer 1

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;
}

Answer 2

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.

Answer 3

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.

Answer 4

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.