Blogging Ottinger (tim)Avoiding Inheritance
This is about object-oriented software design, not getting money from relatives and admirers. If you didn’t get that, then you probably aren’t interested. Or you’re Kim.
In object-oriented design, inheritance is one of our doctrinal distinctives — the things that make us different from non-OO design. But there’s one thing that many designers don’t understand about inheritance… something that would revolutionize their whole approach to OOD and improve their work products by maybe 20 or 30 percent. This little secret is not so obvious, and many OO masters and OO dropouts realized it at the same time. Whether they learned to cope with it or not determined whether they would master OOD or fall off the map. I’ll give you this little tidbit for free:
Inheritance is evil
Well, not exactly, but it’s sort of true. It is to be avoided whenever possible.
Inheritance really has two forms: code reuse, and Liskov-style substitutability.
The latter is acceptable in statically-typed languages because it just has to be so. It’s sad. Programming in statically-typed languages is rather like eating pie in a ski mask. Oh, you can do it, but it’s messy and harder than it would otherwise be. If you have to use statically-typed languages, then you have to deal with that. It’s only in the C-like languages that inheritance creates polymorphism, and they’re the weaker for it.
In the former case, it’s sad. I think that the best way to share code between two modules is to put the code in a third module, and call it from the first two. Inheriting is the worst way. It must only EVER be used for extending (adding to) classes, and never for restricting. Inheriting should only be used when ‘has-a’ fails to satisfy and the only alternative is copy-n-paste (an even greater evil).
If you can change your design to work through composition instead of inheritance, you’ll find that many dark corners in your design will simply vanish. The code becomes more flexible (surprise, that!) and much more easily comprehended. The downside of composition is that whole demeter thing, but we can talk about that later. For now, be pleased to have suddenly learned one of the big design secrets of the century.
The other big secret is that class design is subordinate to object design, but we’ll cover that again later.
I had begun to suspect that “Inheritance is evil” some time ago… but I was afraid to admit it.
Comment by Walter Moore — 2005-December-10 @ 01:26
Feel free to admit it.
IMHO, a lot of the Design Patterns book is all about replacing inheritance with composition in one way or another. Sure, a few of those ways will require inheritance (for statically-typed languages) but overall this is true, and overall you get smaller and better-focused hierarchies by using the patterns.
The goal here should be to have a language of classes for solving problems, and so the correct structure should be heavy on mechanism (many ways to do things) and shy on structure (few restrictions).
We’ve had two cases in the past several weeks where the design is best improved by eliminating inheritance in favor of composition. I think the fact that we continue to experience this reinforces the idea that inheritance should be the fall-back position, not the first design idea we have.
Comment by Tim — 2005-December-13 @ 07:17