C++ Inheritance – Public vs Private Inheritance for Exposing Parent’s Methods

c++11encapsulationinheritance

Public inheritance means that all fields from the base class retain their declared visibility, while private means that they are forced to 'private' within the derived class's scope.

What should be done if some of the parent's members (say, methods) need to be publicly exposed?

I can think of two solution. Public inheritance somewhat breaks encapsulation. Furthermore, when you need to find out where is the method foo() defined, one needs to look at a chain of base classes.

Private inheritance solves these problems, but introduces burden to write wrappers (more text). Which might be a good thing in the line of verbosity, but makes changes of interfaces incredibly cumbersome.

What considerations am I missing? What constraints on the type of project are important? How to choose between the two (I am not even mentioning 'protected')?

Note that I am targeting non-virtual methods. There isn't such a discussion for virtual methods (or is there).

Best Answer

You can expose items that would otherwise have some kind of restricted access (i.e., private or protected) without writing a wrapper function by using the using directive:

class base {
public:
    base();
    virtual ~base();
    void do_something();
    void do_something_else();
private:
    // elided
};

class derived : private base {
public:
    derived();
    virtual ~derived();
    using base::do_something();
};

In the above, the derived class exposes base::do_something() as a public method, but not base::do_something_else().

Related Solutions

C++ – Is it possible to refactor inheritance to composition when virtual methods are called inside the base class

So let's make this concrete-ish.

class Country {
  virtual void foo();
  void bar() {
    foo();
  }
}

Moving toward:

class Country {
  private thingWhichWasSubclass;
  void bar() {
    thingWhichWasSubclass.foo();
  }
}

Is that right? How about as an intermediate step:

class Country {
  private thingWhichWasSubclass;
  void foo() {
    thingWhichWasSubclass.foo();
  }
  void bar() {
    foo();
  }
}

Would that do it? Then (of course) inline Country.foo().

Object-Oriented Programming – Is ‘Protected’ Reasonable Outside Virtual Methods?

Yes.

A situation where a non-virtual protected method makes sense might be something like bool IsInitialized(). The class is designed to be sub-classed. The sub-class might provide new methods, or overriding methods. In either case, before these methods can be run, it is important to check that the class is initialized. So the IsInitialized() method is provided for that purpose. It is intended to be used by the new or overriding methods in the sub-class only, and not the calling code. It is also intended that IsInitialized() not be overridden. The way to provide this is by declaring IsInitialized() to be protected and non-virtual.

Best Answer

Related Solutions

C++ – Is it possible to refactor inheritance to composition when virtual methods are called inside the base class

Object-Oriented Programming – Is ‘Protected’ Reasonable Outside Virtual Methods?

Related Topic