Composite Design PatternThe Composite Design pattern allows a client object to treat both single components and collections of components identically.In the UML class diagram below, the Client uses an abstract component, AComponent, for some abstract task, operation().   At run-time, the Client holds 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.    

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

Note:  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.