Cool software design insight #5

OO helps us hide away the routine problems and the makes the code easier to use. Among the first things you learn with class-based object-oriented (OO) languages like Java and C++ is how to use inheritance. Inheritance is a form of taxonomy for programmers. It makes great-looking diagrams. Pedagogically, it makes type polymorphism easy to understand.

However, I will tell you a little secret: cool programmers do not use inheritance, except maybe to derive new classes from the standard classes provided by the language. Inheritance tends to make code more difficult to maintain. In some cases, inheritance makes software slower.

The better alternatives are:

C++ :
Use templates, they are both faster and easier to maintain than class inheritance.
Java :
Use interfaces. Java interfaces are a bit annoying to maintain, but they do not contribute any bugs.
Python, Ruby, Objective-C, Perl, JavaScript/ECMAScript :
Use duck typing.

8 thoughts on “Cool software design insight #5”

  1. The Javascript object model is quite different and interesting, definitely worth a look if only to see what an alternative to traditional OO looks like. Check out prototypal and parasitic inheritance.

  2. Amen! Duck Typing is awesome. It took me a while to figure out that objects don’t all have to inherit from a class or implement some interface.

    [,,].each {|e| puts e.some_method_they_all_declare }

    Some related advice is “Favor composition over inheritance”. Deep inheritance graphs are a code smell.

  3. I think part of the reason inheritance gets overused is that too much emphasis is placed on it when OO programming is taught. The ubiquitous Shape inheritance diagram springs to mind.

    Java’s analogue to C++’s templates is generics. That’s a whole different can o’ worms but, used sparingly, can also help avoid large, smelly inheritance diagrams.

    I’ve heard Daniel’s advice phrased slightly differently: “Prefer has-a over is-a”. The main advantage of composition over inheritance is that you are more free to modify the implementation of a class that uses another class. Delegation methods and adaptors are easy to write and make your code modular and maintainable.

    If you extend from a class you’re pretty much stuck with the parent’s class implementation unless you start overriding everything which defeats the purpose of inheritance anyway.

    My rule of thumb when considering `B extends A` is to pause and ask, “is B really an A under all possible interpretations or am I just trying to be ‘clever’ and avoid writing a few extra lines of code?”.

  4. I consider myself a cool programmer and well, I sometimes do use inheritance, even though I agree that it is a somewhat problematic language feature.

    As an example, I recently wrote a web app that produced, among other things, a lot of different Atom feeds.

    There, it made sense to create a Feed superclass, that provides some Atom-specific functionality and then derive Feed subclasses that implement the meat of the functionality.

    In this case, inheritance is nothing more than a mechanism for code reuse, and I think its use is warranted.

    OTOH, if I had used a language with generic procedures (methods outside classes), I probably wouldn’t have used inheritance, but rather simple, duck-typed generic procedures.

  5. In some cases I still favor “cowboy programming” on bare metal 🙂
    Depends on what kind of job of course but anyway I think functional programming (Haskell) has more potential than OO though I am not really used to it.
    I always found that OO was a half baked idea.

  6. I think i only half agree with you on this one. I think most professional programmers discover that it’s too hard to create and maintain deep type hierarchies, but i also think there are certain cases where classic OO polymorphism is pretty “cool”.

  7. I agree that inheritance isn’t cool, but sometimes it’s necessary. This is especially true when you want to override some behaviour and the language you are using doesn’t have a meta-object protocol.

Leave a Reply

Your email address will not be published. Required fields are marked *