Deriving from a concrete class?

Question

In book 'Head First Design Patterns', one of the way mentioned to not violate 'Dependency Inversion' principle is as:

No class derive from a concrete class.

Is it possible to follow this rule thoroughly? In many commonly used frameworks and libraries its common to find classes not following this rule.

Answer 1

Deriving from concrete classes is usually bad object oriented design. There are cases when it is more desirable as has been mentioned in other answers. However, it is undesirable as it breaks encapsulation. Good object oriented design is to give yourself options for future change.

You should instead encapsulate the concrete class as a private member and only expose functionality piece-wise from the containing class. This gives you more options in the future in case the encapsulated class needs to be changed.

Answer 2

As problems in programming are very different, it's hard to tell. Sometimes you it's usefull to do it, sometimes it's not.

It's also possible to redesign the situations that you think you can't to actually achieve this. But in the new design you may end up with more classes that you don't really need and are only used to achieve this.

The question in this case is: Is having more stuff just to achieve some principle without having problems in your code a good design?

In my experience it is better to try and avoid inheriting from concrete classes. Try to design you code so that you don't inherit from concrete classes. This will make your code better to read and understand as it guides you to designing your abstractions better. But sometimes it's usefull to do just that.

As you mentioned frameworks do that. Especially GUI frameworks. You see a lot inheritance from concrete classes there. That's because it's usefull to add additional behavior to already existing controls.

For example a Button is fine on it's own, but sometimes you may need to add an additional behavior for your needs. Inheriting from Button and just adding the new things you need is just fine. Can you do it another way? Sure, but is it worth adding addtional classes and/or interfaces or coping code from Button just to avoid inheriting from a concrete class? Is is so bad? Where can it hust?

You do achieve extensibility this way, as the framework will still work just fine.

GUI frameworks also use composition a-lot too, so what you get is a combination of composition with inheritance from both concrete and abstract classes. Just use the right one where you need it.

Not all problems are like that with a hierarchical structure with a a-lot of related objects. Sometimes inheritance can hurt extensibility and using composition is a better choise.

Answer 3

Inheritance is an important part of c#, ruling it out would be a waste.

Nevertheless, the book emphasizes the open for extension closed for change SOLID principle and this is actually a good thing.

Not to derive from concrete classes ( note, abstract classes and interfaces are not concrete ), helps you to adapt this paradigm. Inheritance is not typically suited for extension, and makes inversion harder ( because the latter relies on interfaces and concretes are not interfaces ).

So in practice, you'll see that base classes are often abstract. Not all, and not every framework adopts it. Sometimes there are good reasons to inherit from a concrete. But the book, is in it's way a easy read and to go into details on the exceptions would make it much harder to read.

So bottom line: no, one should not follow the rule at all cost but only do concrete inheritance if one of the following:

• you know what you are doing (so you have a really really really good reason)
• you know it doesn't matter ( because it's a simple project/object)
• you know the concretes will be contained to the project itself (internals)