Case to inherit a nontrivial class?

Question

I was reading on the sealed keyword in C#. I cant remember the last time i inherit from a standard library. In c++ I remember inheriting an std interface that typedef a few types and used some of my parameters. But that is 1) Trivial 2) An interface

From the top of my head, i dont remember any class that i inherited that didnt have a virtual function expecting to be inherited. Can anyone tell me of a situation where you needed to inherit a non trivial class that wasnt an interface?

I might even say its a good rule to thumb not to inherit a class unless it has virtual functions. Is this a good rule of thumb?

NOTE: I use operator SomeClass& SomeClass() { return m_someClass; } in the case i need to pass my object as another class. It works well.

Answer 1

It is actually used in C++, for all these not-is-a kinds of inheritance (eg. inheriting an implementation, mixins, boost::noncopyable, where you inherit from it and make your class noncopyable, boost::operators where you inherit from some class and it will add some operators to your class). Also, when doing metaprogramming with C++ types, inheriting from another type(s) is one of the simplest methods of composing types.

Another case where you inherit from a class that doesn't have virtual functions, but serves as "kind of" an interface, is static polymorphism (techniques like CRTP, where class ConcreteA : BaseA). They don't need the virtual functions, because everything is resolved at compile-time.

However, if you want to treat your class runtime-polymorphically, you should really make at least one method virtual, and that would be the destructor. There are exceptions, but rare.

Even when you have a polymorphic hierarchy, you sometimes derive from concrete classes. One example would be a SingleLineEdit deriving from TextEdit. However, this is a little dangerous, because it breaks encapsulation of the parent class (eg. its methods may expect some implementation details, and you must respect and preserve them in the subclass - which may be tricky, since they are implementation details that may change without notice in the next version etc.)

Answer 2

I would argue that the key concept of object-oriented programming is polymorphism. If inheriting from a particular class doesn't allow you to take advantage of polymorphism, then what is the point of inheriting? So if there are no methods to override, then do not subclass. You'd only be increasing the complexity of your code. If you want a lot of the same functionality, just wrap the existing class in your own.