Click here to Skip to main content
12,405,270 members (61,685 online)
Click here to Skip to main content
Add your own
alternative version


13 bookmarked

Composite Design Pattern - an Example

, 29 Jun 2005 Public Domain
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
Architect som-itsolutions
India India
The best way I can describe myself is as a dream chaser. In the beginning of my career, being in the marketing department of a big telecom company, which hardly added any values to my curiosity, I was hell-bent to jump into the software because that was the only way to know about the nitty-gritty of the hardcore technical aspects. Hence I started with learning C++/VC++. But in the beginning it was really difficult without much idea about programming. Moreover, there was no google. I took a little more time to pick up. There was no training. Absolutely no help from anybody. No broadband internet. No computer at home. It was really difficult for me. But I did not stop dreaming. I used to dream and tell my colleagues that C++ is not as much about programming as about designing. It is more about a technique for moving from the problem domain to the solution domain. However, I hardly got any supports from the organizations where I worked. It was only when I got a PC at home, I started walking towards my goal. The early morning rise, innumerable visits to technical book stores in Bangalore, googling and traversing from one link to another in search for technical and C++ contents, becoming tired after the office hours, all were part of it. But still the road was difficult. I was not able to join the dots. And then when I started going through the Design Pattern book, the actual joy of learning began. Still I remember how I used to go through the MFC source code to map different GoF patterns in Doc-View architecture, the command-routing architecture and so forth. However, I was not much aware of the Open Source communities. Then when Google made their Android framework open, it was a boon for me. I picked up many unknown areas and started looking into code from a designer’s perspective. When i started understanding the Android framework code, I thought I was really able to join the dots.The dots between the dream and the reality to become an able software engineer…..

You may also be interested in...

Comments and Discussions

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    Praise Praise    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
Web02 | 2.8.160721.1 | Last Updated 30 Jun 2005
Article Copyright 2005 by mukhopadhyay somenath
Everything else Copyright © CodeProject, 1999-2016
Layout: fixed | fluid