Is inheritance of concrete classes evil? [closed]

Answer 1

You can privately derive from concrete classes. Private inheritance doesn't require Liskov substitutability; it's essentially just a convenient way to "mix in" a class's functionality.

Public inheritance, on the other hand, does require Liskov substitutability. So, usually, publicly inheriting from concrete classes is a bad thing, unless such a class is designed to be used as a base class (many are not).

Answer 2

Not a C++ guy (have professional experience with big enterprise systems in c#, java, and ruby), but here is my 2 cents anyways

This isn't a black and white thing.

The problem with inheritance is that it introduces tight coupling. Worse, that coupling is usually around encapsulated state. Changes in super classes can have rippling effects down inheritance hierarchies, creating subtle and hard to predict bugs.

Interface segregation totally sidesteps those issues, because it doesn't break encapsulation the same way.

The good thing about inheritance is that sometimes you have an object model that really is the same thing, just with a very small change or addition. As long as that change is very clear, not wide reaching in scope, and isn't an additional constraint (see the circle-ellipse problem), the code reuse will trump the tight coupling.

I stick to composition over inheritance as a rule of thumb, not a law.

Answer 3

Good design stipulates that concrete classes should do a single, relatively small thing well and efficiently. Especially in C++, concrete classes emphasize their similarity to concrete types like int and char, often by operator overloading and by having only non-virtual functions. As concrete classes are not intended to display polymorphic behavior, they should not be inherited. Also see section 25.2 of The C++ Programming Language for more information on the proper use of concrete types in that language.