This document describes how the Composite Design Pattern has been implemented in Android View and Widgets.

1. Implementation of Composite
Design 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 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:

2. 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 basecorejavaandroid) 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

3. 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.

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