FAQ 7.06 Is it proper to revoke (hide) an inherited public: member function?

FAQ 7.06 Is it proper to revoke (hide) an inherited public: member function?

No.

Never. The rest of the software was written based on the promises made by the base class (see FAQ 6.02). Since the main idea of polymorphism and dynamic binding is to pass a derived class object to a function that takes a base class pointer or reference, this "rest of the system" often works with derived class objects without knowing it (see FAQ 2.24). Everything works fine as long as the derived class objects behave like the base class promises they will behave. However if the derived class is not substitutable for the base class, all that code that was written based on the base class's promises (the "rest of the system") will break.

In order to be substitutable, the derived class object must support all the member functions of the base class. If even one of the member functions promised by the base class has been revoked (hidden) by a derived class, a large portion of the rest of the system could break.

Public inheritance requires keeping promises and hiding or revoking promised behavior will surprise the rest of the system. Too often, programmers try to use inheritance even when it doesn't fit the constraints of substitutability. Typically this means creating a derived class, then trying to revoke (hide) whatever inherited public: member functions don't make sense in the derived class.

Revoking an inherited public: member function is evil.

Recall that this chapter covers the guidelines for public inheritance. private and protected inheritance are different: it is appropriate and proper to revoke (hide) inherited public: member functions in a private or protected derived class (see FAQ 37.01).