Question: I was reading about [NonVirtual Interface pattern](http://www.gotw.ca/publications/mill18.htm): Herb Sutter is talking about why virtual function must be private in most of the case, protected in some case and never public. 

 But at the end of the article he write:

> 
> Don't derive from concrete classes. Or, as Scott Meyers puts it in Item 33 of More Effective C++,[8] "Make non-leaf classes abstract." (Admittedly, it can happen in practice - in code written by someone else, of course, not by you! - and in this one case you may have to have a public virtual destructor just to accommodate what's already a poor design. Better to refactor and fix the design, though, if you can.)
> 
> 
> 

But I don't understand why this is a poor design

Answer: 
A problem with inheriting from a concrete type is that it creates some ambiguity as to whether code which specifies a certain type really wants an object of the specific concrete type, or wants an object of a type which behaves in the fashion that the concrete type behaves. This distinction is vital in C++, since there are many cases where operations which will work correctly on objects of a certain type will fail badly on objects of derived types. In Java and .NET, there are many fewer situations where one can use an object of a particular type, but could not use an object of a derived type. As such, inheriting from a concrete type isn't nearly as problematical. Even there, however, having sealed concrete classes which inherit from abstract classes, and using the abstract class types everywhere except in constructor invocations (which must use the concrete types) will make it easier to change parts of the class hierarchy without breaking code.
In general, it's difficult to strictly maintain a contract between two distinct concrete objects.

Inheritance becomes really easier and more robust when we deal with generic behavior.

Imagine that we want to create a class named `Ferrari` and a subclass named `SuperFerrari`.
Contract is: `turnTheKey()`, `goFast()`, `skid()` 

At first glance, sounds like very similar class, with no conflict. Let's go with inheritance of these both concrete classes.

However, now we want add a feature to `SuperFerrari`: `turnOnBluRayDisc()`.

Problem: Inheritance expects a IS-A relationship between components. With this new feature, `SuperFerrari` is not a simple `Ferrari` any more with its own behavior; it now ADDS behavior . 
It would lead to some ugly code, with some cast needed, in order to choose the new feature while dealing with a `Ferrari` reference initially (polymorphism).

With an abstract/interface class in common to both classes, this problem would disappear since `Ferrari` and `SuperFerrari` would be two leafs, and it's more logic since now `Ferrari` and `SuperFerrari` should not be consider as similar (not a IS-A relationship any more).

**In short, derive from concrete class would lead in many cases to a poor/ugly code, less flexible, and hard to read and maintain.**

Making a hierarchy driven by abstract class/interface allow concrete children classes to evolve separately without any issues, especially when you implement some subhierarchies dedicated to a special amount of concrete classes without boring others leafs, and still benefit from polymorphism.