Home > Best Practices, Design Patterns, Opinion, Random Notes > The importance of Composition

The importance of Composition

February 4th, 2009

Many times when we are designing our programs model, first thing most people, including myself, want to start doing is inheriting from other classes. This makes for a nice large hierarchical beast. Not that there is anything wrong with that, but it can lead to certain problems (from my own personal experience, it usually does). With composition, the programmer no longer has to extend from the parent class. You are able to expose only the methods you are interested in. In this article, I really want to discuss the importance of composition. I feel as programmers, many of us find inheritance easier and we often use it without thinking about the repercussions it may bring to us.

I would like to just give a quick example of composition. If you have some sort of base class that your application will be inheriting from, lots of times you just extend it.

public class BaseClass{
    public void doStuff(){...}  
}
public class NewBaseClass extends BaseClass{...}

Nothing wrong with that and it is quite common to use. Another way we could do this is:

public class NewBaseClass{
    private BaseClass _baseClass;
    public void setBaseClass(BaseClass baseClass){
        _baseClass = baseClass;
    }
    public void doStuff(){
        _baseClass.doStuff();
    }  
}

Using the typical example of “IS-A” vs “HAS-A”, the first example IS a BaseClass. The second example HAS a BaseClass. From this example, it is difficult to see the advantages that something like this has to offer us. The laziness factor that almost all programmers have kicks in when they see we have to write functions that call the same functions on the BaseClass. While on the outside, it may seem like we are just doing extra work for no reason, there are many advantages that this approach has to offer.

When you use inheritance, you acquire the functionality of your baseclass at compile time. Note that in my short composition example, we have a setter for our BaseClass. This is because with composition, you acquire your functionality at runtime. Once again this might difficult to see the importance. When we assign something at run-time, it gives us the ability to swap out implementations without having to recompile our code. In fact, the decorator pattern, amongst many other design patterns, take advantage of composition by this technique alone. You are able to just write however many BaseClasses you want and swap out the implementation at runtime.

I love the use of interfaces. To me, they are the greatest thing next to sliced bread. However, I cannot think of one instance where I worked on a project where the interface did not change in some form or another. New methods get added, old methods get removed, types change, etc. It is the standard rule of thumb that when using an interface, make sure you have done it right the first time. Once that interface is published and goes to the client, that is it. Once you change that interface, everyone elses code breaks. Now if instead of using inheritance, we took advantage of composition, we would not have to worry about it. The interface can add as many methods as it wants, there is much less of a change that it will break (if they remove the function, then not much you can do about it). With composition, we only expose the methods that we want to use. We no longer have to worry about relying on the parent class or implementing their functions.

When designing out projects, it is very easy to design things while you are thinking a problem through. When you are doing this at the design level, lots of people will just inherit from parents classes. A implements B, C extends B, etc,etc. But what if D needs some functions from C but not from B? Surely you could always just implement what is in C that you dont need and not do anything with it, but that is just poor design. You could create another hierarchal level and go from here, but this is where trouble begins. You now have this extremely large, tightly coupled and difficult design to follow. The alternative approach would be to use composition. Using this, we will have fewer classes to worry about in our design and we will have much more diverse objects. Following this, when we have fewer classes, our hierarchy becomes smaller and more focused, thus easier to follow.

Now this is not to say inheritance is bad and should be avoided. There are many instances required. However, I do feel that it is often abused. Partly because programmers are naturally lazy and its much easier to extends a class rather than expose the methods on a class. The other reason though is (I feel) its a methodology that is often overlooked. With the use of composition in your code, you will be able to produce a much more flex and stable application.

Best Practices, Design Patterns, Opinion, Random Notes , ,

  1. Mark
    February 12th, 2009 at 22:31 | #1

    Great explanation. It’s all about the loose coupling in our designs.

  2. Faisal
    March 24th, 2009 at 04:22 | #2

    Thanks dear,for explaining things in such a nice manner.

  3. Silesh Girma
    April 6th, 2009 at 10:57 | #3

    it is very very god but you should have to be add more information.

  4. Amit V
    July 26th, 2009 at 07:09 | #4

    Example would help in a much better way.

  5. ac
    October 8th, 2009 at 09:40 | #5

    very clear… keep it up, thank you

  6. November 29th, 2009 at 23:29 | #6

    Appreciate it.
    It’s nice comparison

  7. Sudip Purkayastha
    April 6th, 2010 at 14:12 | #7

    Very nice article

  8. prakyat
    May 13th, 2010 at 17:00 | #8

    wonderful article.. very clean and clear in explanation.. However a simple example would have been (wonder)2

  9. Dase
    August 4th, 2010 at 05:35 | #9

    the best lecture ever heard on composition. Thanks for the great will to share.

  10. jeetender
    October 7th, 2010 at 13:39 | #10

    very good example of composition and very easy to understand

    Thanx

  11. James
    November 11th, 2010 at 20:10 | #11

    This essentially sounds like dependency injection.

  12. Rajiv
    May 12th, 2011 at 23:51 | #12

    Wonderful Article Thanks

  13. Avinash
    October 18th, 2011 at 07:57 | #13

    It’s nice article..

  14. Ajit Nalawade
    December 20th, 2011 at 10:37 | #14

    Awesome explanation dude…thnks

  15. September 20th, 2012 at 06:59 | #15

    Really great explanation of Composition.

  16. nitin
    February 8th, 2013 at 06:42 | #16

    Nice explanation.

    In article mention about “…Once you change that interface, everyone elses code breaks…”.

    I agree because of some reason such cases do arise which are out of control

    But there is a solution wich has minimum impact.

    1. Instead of breaking code apply “The Interface Segregation Principle(ISP)”
    a. Separation Through Delegation
    b. Separation Through Multiple Inheritance.

    2. Developer should think from abstract layer, identify group of objects/classes falls under hierarchy and not just blindly do inheritence.

    Let me know if i am wrong.

  17. Sandeep
    February 27th, 2013 at 13:32 | #17

    Best article i never seen…

  18. amarjit
    March 26th, 2013 at 01:43 | #18

    Seems like in this way it can achieve Multiple Inheritance logic also.

    ????

    public class BaseClass1{
    public void doStuff1(){…}
    }
    public class BaseClass2{
    public void doStuff2(){…}
    }

    public class NewBaseClass{
    private BaseClass1 _baseClass1;
    public void setBaseClass(BaseClass1 baseClass1){
    _baseClass1 = baseClass1;
    }
    public void doStuff1(){
    _baseClass1.doStuff1();
    }

    private BaseClass2 _baseClass2;
    public void setBaseClass(BaseClass2 baseClass2){
    _baseClass2 = baseClass2;
    }
    public void doStuff2(){
    _baseClass2.doStuff2();
    }
    }

  1. February 3rd, 2010 at 10:35 | #1