Implementation of CompositeDesign Pattern in Android View

and Widgets

by

Somenath Mukhopadhyay

som.mukhopadhyay@gmail.com

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 objectsuniformly".

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

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

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 children2. these are the primitive objects

Composite -

1. defines behavior for components having children2. 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 letus try to dissect the Android View and the Widget folders (which areavailable at \\base\core\java\android) to see how this design pattern hasbeen implemented there.

In Android, the View class works as the Component class. However, thechild management part (add component, remove component) has been

moved to the Composite class which is the ViewGroup class. Actually theAdd and Remove of a component has been declared in an interface calledViewManager and the ViewGroup implements that interface. Also theinterface for a Composite object is declared as ViewParent interface andthe ViewGroup (the Composite object) implements that as well.

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

As expected the getParent function which is needed to get the Parent of acomponent 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 asfollows-

Now let us consider the class diagram as presented in the beginning ofthis discussion. There is a function called Operation. In Androidimplementation, the onDraw function in the Component (View) plays thisrole. The DispatchDraw function (which is called when the Component isto be drawn) in the composite (ViewGroup) object actually traversesthrough 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 some sort ofimplementation of the Composite Design Pattern.