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: 
I think this is because concrete class has concrete behavior. When deriving from it, you are committed to retain the same "contract", but the actual contract is defined by the specific implementation of the base class, and in reality will have many subtleties you will probably break without knowing.

Disclaimer: I am not an experienced developer; it is just a suggestion.
When you derive from a concrete base class you inherit functionality, which may not be revealed to you if you do not have the source code. When you program to an interface (or abstract class) you don't inherit functionality meaning it it a better way to do things like expose an API. That being said I think that there are plenty of times when inheriting from a concrete class is acceptable