Composite Design Pattern 1.1 2007/07/25 17:32:48.539 GMT-5 2007/07/25 18:00:00.251 GMT-5 Stephen Wong swong@rice.edu Stephen Wong swong@rice.edu composite design object oriented pattern programming The Composite Design Pattern is an object-oriented representation of a recursive data structure.

Description The Composite Design Pattern allows a client object to treat both single components and collections of components identically.    It accomplishes this by creating an abstraction that unifies both the single components and composed collections as abstract equivalents. Mathematically, we say that the single components and composed collections are homomorphically equivalent (from the Latin: homo – same and morph – form ==> to have the same form). This equivalence of single and composite components is what we call a recursive data structure. In recursive data structures, objects are linked to other objects to create a total object structure made of many “nodes” (objects). Since every node is abstractly equivalent, the entire, possibly infinitely large and complex data structure can be succinctly described in terms of just three distinct things: the single components, the composite components and their abstract representation. This massive reduction in complexity is one of the cornerstones of computer science. The Composite Design Pattern is an object-oriented representation of a recursive data structure.

UML Diagram and Example In the UML class diagram below, the Client uses an abstract component, AComponent, for some abstract task, operation().   At run-time, the Client may hold a reference to a concrete component such as Leaf1 or Leaf2.   When the operation task is requested by the Client, the specific concrete behavior with the particular concrete component referenced will be performed.    

UML Diagram of Composite Design Pattern Example An example of a composite design pattern implementation with 2 single, concrete components and one composite, collection component.

The Composite class is a concrete component like Leaf1 and Leaf2, but has no operation() behavior of its own.    Instead, Composite is composed with a collection of other abstract components, which may be of any other concrete component type including the composite itself.   The unifying fact is that they are all abstractly AComponents.   When the operation() method of a Composite object is called, it simply dispatches the request sequentially to all of its "children" components and perhaps, also does some additional computations itself.     For instance, a Composite object could hold references to both a Leaf1 and a Leaf2 instance.   If a client holds a reference to that Composite object and calls its operation() method, the Composite object will first call operation on its Leaf1 instance and then operation() on its Leaf2 instance.   Thus composite behavior of Leaf1 plus Leaf2 behaviors is achieved without either duplicating code or by having the Client object knowing that the two leaf components were involved.   Composite patterns are often used to represent recursive data structures.    The recursive nature of the Composite structure naturally gives way to recursive code to process that structure. The collection of AComponents held by Composite, "children", is shown above as an array.   However, the behavior of a Composite pattern is independent of exactly how the collection of AComponents is implemented.   If access speed is not an issue, a vector or a list may be a better implementation choice.    The addChild() and removeChild() methods are optional. In Design Patterns, the abstract component AComponent is shown as having accessor methods for child AComponents.   They are not shown here because it is debatable as to whether one wants the Client to fundamentally view the AComponent as a single component or as a collection of components.   Design Patterns models all AComponents as collections while the above design models them all as single components.   The exact nature of those accessor methods is also debatable.