A Funny Java Flavoured Look at the World

Sunday, November 12, 2006

Favouring composition over inheritance is a sign of a maturing programmer

I'm not entirely sure what I am basing this theory on but I believe that favouring composition over inheritance is when a programmer/developer is maturing into a better programmer who creates code that is easier to maintain and extend, along with solving the problem you are writing the code for the two main goals of my coding.

I wrote an article about why you should use Composition instead of inheritance and as always the comments for this post were very interesting.

It's just a personal opinion of course but initially I use to think first of using inheritance because it seems easy and you can use code in the base class in all the classes that inherit this class. I think this is why people favour inheritance.

I think the next step of evolution as a programmer is using interfaces as a way to protect against change in the future.

The next stage that perhaps I am at (what I like to think, my work colleagues may disagree) is that you start to use composition. I have stopped thinking that the best code is the least amount of code written, which was one of the reason I use to use inheritance. I now think of good code as code that has loose coupling and that does one thing i.e has high cohesion. This type of code can easily be reused and change in any part of the code will hopefully affect a small part of the code base. Code should be DRY and many other things but I am not talking about that kind of code intricacies but sort of looking at the code at a more holistic view.

I believe that favouring composition is way to achieve the code above. I would like to get it clear that I am not against using inheritance and there is a time and place for using it when it's the best option etc. What I am trying to say is that there was a stage where I would try to use inheritance a lot but then over time I have stopped doing this and the reason for this is because I think my coding has matured and the goals of code I am trying to create have changed.

I'm not really sure when the change of thought process occurred but I will now spend a bit more time creating code like the above to try and manage the complexity of the code and the effect of change on the code. Of course this can also be abused with the creation of a million to many classes, as with everything there is a balance to achieved but more classes maybe better than too few because at least change is more likely to be isolated then.

I would like to know what other people think about this and what's the next stage of development of a programmer



If you like this blog or and fancy something a bit less technical with some laughing thrown in then check out my other blog Amusing IT Stories. Which is a blog about funny and amusing stories from the IT environment and the office. It is a mix of news, office humour, IT stories, links, cartoons and anything that I find funny



7 Comments:

  • You are not alone with this theory, and actually, it's not a theory but practise experience. When I was working on the alias problem of OO languages by using some kind of confinement, compositon is the better way to bundle contexts and to encapsulate them. You always can define what to bundle in a class, but a superclass never knows which subclasses exists.

    Interfaces: in my opinion, they are supervalued. They are sometimes good hiding the implemention, they are good in server-client communication, they are good to replace multiple inheritance, but they can make a lot of trouble (class casting necessary; not knowing how something is implemented although it would make sense; debugging complications). So I would recommend: use interfaces, but only when necessary but do not just for a clear design. You don't want to handle interfaces, you want to handle with objects. Actually, every object has already its own interface (public methods and arguments).

    By Blogger Mario Bertschler, at Sun Nov 12, 09:30:00 pm 2006  

  • Well, really what you're saying is that classes are too tightly coupled. But really, that says to me that the classes just haven't been designed correctly. You just need to reduce the coupling between a class and those that extend it.
    Really, that's what composition does. You can only access public methods of the object you're delegating to (pseudo superclass instance), so the loose coupling is just being more strictly and explicitly enforced.

    By Anonymous Anonymous, at Sun Nov 12, 11:08:00 pm 2006  

  • In case it wasn't clear enough, I was advocating for properly-designed classes and inheritance, not composition.

    By Anonymous Anonymous, at Sun Nov 12, 11:10:00 pm 2006  

  • One of the main problems with inheritance is by it's nature the classes have to be tightly coupled and this can lead to problems later on.

    they are tightly coupled because one class extends another.

    By Blogger The Hosk, at Mon Nov 13, 12:51:00 am 2006  

  • i agree with your thining but we arrived at the same point via different routes. I've been using hibernate for quite a few years and it was always difficult or inefficient to use inheritence with a relational database, using composition is far more efficient.

    By Blogger grahamoregan, at Mon Nov 13, 09:43:00 pm 2006  

  • "I have stopped thinking that the best code is the least amount of code written, which was one of the reason I use to use inheritance."

    Interestingly, composition doesn't have to mean more code. If you normally inherit your method implementations from a superclass, and instead start to use composition, then you'll probably start writing delegating methods so that your client code can still call those methods in the same way.

    However, there's no real reason for that. You can let the client code call the original method directly. Typically you end up with syntax such as operateOn(object), rather than object.operate(), but that's ok. It's still OOP, just with thin objects.

    By Blogger Ricky Clarkson, at Tue Nov 14, 11:53:00 am 2006  

  • Composition is good!! It is not possible to use inheritance anymore because software is not as simplistic as when OO was new. You'll never be able to concretely say that your subclass realy does hold up to all the "is-a" relationships. Unless you're designing the library it's not sensible to subclass.

    The worst part of all this is all the poor visual builders I know of. They all force you to subclass some component, as if your comment entry tool "is-a" window. You then end up with countless serializable instances you now have to worry about, when before you mucked around with this garbage you were getting serialization for free: for all that work you put into javax.swing.JFrame. Perhaps now that source is freed more developers will begin to feel the same weight of instantly obsolete software as they code "extends"....

    nice technical article.

    By Anonymous Anonymous, at Fri Nov 17, 10:34:00 pm 2006  

Post a Comment

<< Home