Skip to Content

The Intent of the composite design pattern is stated in the GoF book as “Compose Objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly”.


To explain it in a simpler fashion, let me give the same example as given in the GoF book. Suppose there is an object called Picture, a graphics object. This picture may consist of other pictures recursively as well as primitive objects like line, rectangle objects etc. All of these part objects which make the whole picture conform to the same Graphic interface. Hence to the client, a part object appears same as the whole picture consisted of other part objects. To draw a whole object, the client simply traverses through the whole picture and draws different parts.


The class diagram of the composite design pattern will look like the following:


The following participants take part in this design pattern:


Component –


  1. it declares the interface for the objects ( part as well as whole)
  2. helps in managing the objects (adding, removing)


Leaf –

  1. represents leaf objects which don’t have any children
  2. these are the primitive objects


Composite –

  1. defines behavior for components having children
  2. stores the children


Client –

  1. takes help of the Component interface to manipulate different objects


Its all about the theoretical side of the Composite Design Pattern. Now let us try to dissect the Android View and the Widget folders (which are available at \\base\core\java\android) to see how this design pattern has been implemented there.


In Android, the View class works as the Component class. However, the child management part (add component, remove component) has been moved to the Composite class which is the ViewGroup class. Actually the Add and Remove of a component has been declared in an interface called ViewManager and the ViewGroup implements that interface. Also the interface for a Composite object is declared as ViewParent interface and the ViewGroup (the Composite object) implements that as well.


The leaf classes like Button, ImageView etc are deduced either by directly subclassing the View (Component) or from the subclasses of the View (for example, the Button class is derived from TextView class which in turn is directly derived fron the View class). The Composite Class (ViewGroup) is deduced by directly subclassing the View and by implementing the two interfaces namely ViewParent (which defines the interface of a composite object) and ViewManager (which defines the interface from adding and removing components).


As expected the getParent function which is needed to get the Parent of a component is put in the View class (the Component).


The Composite object (ViewGroup) has an array to hold its children.


The simplified version of the Android view and widget’s class diagram is as follows-


Now let us consider the class diagram as presented in the beginning of this discussion. There is a function called Operation. In Android implementation, the onDraw function in the Component (View) plays this role. The DispatchDraw function (which is called when the Component is to be drawn) in the composite (ViewGroup) object actually traverses through the list of the objects and calls draw on each of the child object.


This way we can say that Android View and Widgets are an implementation of the Composite Design Pattern.


To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply