Click here to Skip to main content
11,583,484 members (68,200 online)
Click here to Skip to main content

Composite Design Pattern - an Example

, 29 Jun 2005 Public Domain 50.2K 728 13
Rate this:
Please Sign up or sign in to vote.
Composite design pattern through an example



Composite design pattern is a structural pattern in which we compose the whole-part relationship in a symmetric hierarchy. The client of the composite treats all the objects in the same fashion.

The whole concept of this design pattern lies in the fact that we can treat a composite object which consists of several other objects the same way as a leaf object. The client never knows that it is working on an object which has many other objects inside it.



Let us try to understand the composite pattern with an example. Here we have defined a class namely Shape, which is acting as the root of all the objects in the example. We have put all the basic functionalities of a graphical object in this class. These functions are Add (for adding a component), Remove (for removing a component), GetChild (for getting a pointer to a child), GetParentOfComponent (which will return the parent of a component) and Draw (to draw a component).


Now from the Shape class, we have derived other graphic classes, like Point, Line and Rectangle. Among these classes, class Point is working as an helper class to define classes like Line and Rectangle. We have deduced another class called Picture which is composed of these component classes.


The interesting point here is that, we have tried to implement the leaf classes, namely Line and Rectangle as final classes by making their constructors private and providing static member functions to create them.


The Picture class is composed of these leaf objects (Line and Rectangle).


The Shape class is called as the Component class, the Line and Rectangle classes are called the Leaf classes and the Picture class is called the Composite class.


Another interesting part of the example is that here every component is identifiable through its resource id. Whenever we create an object (leaf or composite object), it creates a key pair of the id and the pointer to that object and pushes this key into a MAP, from which we can easily search for that component in later times through its resource id.




There are many issues to consider when implementing the composite pattern.


  1. We have defined one function called GetParentOfComponent. This can be useful to traverse the whole hierarchy of parent-child relationship. We have to make sure that any child can have only a composite object as its parent. We have ensured it by defining an Exception class which will be thrown the moment we want to add a component to a leaf object. 
  2. It should be noted that the functions like Add and Remove have been defined in the root class. Although for leaf classes, it does not do any meaningful things except throwing an exception, but it gives us transparency, because we can treat all components uniformly.
  3. If we define these functions at the composite class level, then it would give the safety, because any attempt to Add or Remove from the leaf classes would give compile time error, but we would loose the transparency. The composite and the leaf classes will have different interfaces in this case.



The main participants in this design pattern are

  1. Component (Shape) : It basically works as an abstract class which provides a common interface which will be used by the client to treat different classes uniformly. The common functionalities (e.g. Display) have been defined here. Other functionalities like Add, Remove, etc have been put in this class to maximize the role of this interface. The default behavior for Add and Remove has been implemented in such a fashion that for a leaf class, these functions will throw exceptions.
  2. Leaf (Line, Rectangle, etc) : It represents a leaf objects in the composition. Leaf objects cannot have any children.
  3. Composite (Picture) : It stores child components.
  4. Client: It manipulates the objects through the common interface exposed by the Component class.






This article, along with any associated source code and files, is licensed under A Public Domain dedication


About the Author

mukhopadhyay somenath
Software Developer (Senior)
India India
An Engineering graduate in Electronics & TeleComm having 10 years of experience in software development. Interested in object oriented technonologies, specifically in C++, Design Pattern, Java etc. Have developed interests in Agile Programming, SCRUM, Test Driven Development etc. A receptive programmer, a good team player and believe in working in collaboration.

You may also be interested in...

Comments and Discussions

GeneralTransformation of user-defined Objects to XML using Composite Pattern Pin
mbhat30-Dec-07 7:29
membermbhat30-Dec-07 7:29 
GeneralRe: Transformation of user-defined Objects to XML using Composite Pattern Pin
Scott Dorman30-Dec-07 8:35
memberScott Dorman30-Dec-07 8:35 
GeneralRe: Transformation of user-defined Objects to XML using Composite Pattern Pin
Paul Conrad31-Dec-07 7:49
memberPaul Conrad31-Dec-07 7:49 
GeneralRe: Transformation of user-defined Objects to XML using Composite Pattern Pin
Jarno Burger20-Mar-09 12:20
memberJarno Burger20-Mar-09 12:20 
Generalhmm... Pin
Maximilien30-Jun-05 4:08
memberMaximilien30-Jun-05 4:08 
GeneralRe: hmm... Pin
somenath30-Jun-05 5:50
membersomenath30-Jun-05 5:50 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Terms of Use | Mobile
Web04 | 2.8.150603.1 | Last Updated 30 Jun 2005
Article Copyright 2005 by mukhopadhyay somenath
Everything else Copyright © CodeProject, 1999-2015
Layout: fixed | fluid