Effective C++: discouraging protected inheritance?

 

I was reading Scott Meyers' Effective C++ (third edition), and in a paragraph in Item 32: Make sure public inheritance is "is-a" on page 151 he makes the comment (which I've put in bold):

This is true only for public inheritance. C++ will behave as I've described only if Student is publicly derived from Person. Private inheritance means something entirely different (see Item 39), and protected inheritance is something whose meaning eludes me to this day.

The question : how should I interpret this comment? Is Meyers trying to convey that protected inheritance is seldom considered useful and should be avoided?

(I've read the question Difference between private, public, and protected inheritance as well as C++ FAQ Lite's private and protected inheritance section, both of which explain what protected inheritance means, but hasn't given me much insight into when or why it would be useful.)

Some scenarios where you'd want protected:

  • You have a base class with methods where you know you never want to expose the functionality outside, but you know will be useful for any derived class.

  • You have a base class with members that should be logically used by any class that extends that class, but should never be exposed outside.

    • Thanks to multiple inheritance you can play around with base classes' inheritance type and construct a more diversed class with existing logic and implementation.

    A more concrete example:

    You could create a few abstract classes that follow Design Pattern logic, lets say you have: 

    Observer
Subject
Factory

    Now you want these all to be public, because in general, you could use the pattern on anything.

    But, with protected inheritance, you can create a class that is an Observer and Subject, but only protected factory, so the factory part is only used in inherited classes. (Just chose random patterns for the example)

    Another example:

    Lets say for example you want to inherit from a library class (not that I encourage it). Lets say you want to make you own cool extension of std::list<> or a "better" shared_ptr .

    You could derive protectedly from the base class (which is designed to have public methods).
    This will give you the option to use your own custom methods, use the class' logic, and pass the logic to the to any derived class.

    You could probably use encapsulation instead, but inheritance follows the proper logic of IS A (or in this case IS sort of A)

    He isn't exactly discouraging protected inheritance, he just says that he hasn't found any good use for it. I haven't seen anyone either elsewhere.

    If you happen to find a couple of really useful use cases, you might have material to write a book too. :-)

    Yes and no. I myself think that protected inheritance is a bad feature too. It basicly imports all the base class's public and protected members as protected members.

    I usually avoid protected members, but on the lowest levels requiring extreme efficiency with a compiler with bad link-time optimization they are useful. But everything built on that shouldn't be messing with the original base class's (data) members and use the interface instead.

    What I think Scott Meyer is trying to say, is that you can still use protected inheritance if it solves a problem, but make sure to use comments to describe the inheritance because it's not semantically clear.

    链接地址: http://www.djcxy.com/p/78562.html

    上一篇: “编程接口”意味着什么？

    下一篇: 有效的C ++：不鼓励受保护的继承？