Composite Design Pattern
This page is part of the The 'Gang of Four' Companion dedicated to the formal specification in LePUS3 and Class-Z of patterns from the 'Gang of Four' catalogue [Gamma et al 1995].
Download:
The informal description: Excerpts from [Gamma et al. 1995] (adapted for this purpose):
Intent: Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.
Structure: Original OMT diagram converted to UML (Why and How?):
Participants:
Collaborations: Clients use the Component class interface to interact with objects in the composite structure. If the recipient is a Leaf, then the request is handled directly. If the recipient is a Composite, then it usually forwards requests to its child components, possibly performing additional operations before and/or after forwarding.
Sample implementation: The following UML Collaboration Diagram illustrates how the objects in the AWT implementation of the Composite pattern are organized into a tree structure, and how the message numListening can is passed down objects in this tree:
See also:
 |
| Composite pattern in LePUS3 (legend) |
|---|
| Composite pattern in Class-Z (legend) |
From [Gamma et. al 1995]:
Graphics applications like drawing editors and schematic capture systems let users build complex diagrams out of simple components. The user can group components to form larger components, which in turn can be grouped to form still larger components. A simple implementation could define classes for graphical primitives such as Text and Lines plus other classes that act as containers for these primitives.
But there's a problem with this approach: Code that uses these classes must treat primitive and container objects differently, even if most of the time the user treats them identically. Having to distinguish these objects makes the application more complex. The Composite pattern describes how to use recursive composition so that clients don't have to make this distinction.
The key to the Composite pattern is an abstract class that represents both primitives and their containers. For the graphics system, this class is Graphic. Graphic declares operations like Draw that are specific to graphical objects.
The subclasses Line, Rectangle, and Text (see preceding class diagram) define primitive graphical objects. These classes implement Draw to draw lines, rectangles, and text, respectively. Since primitive graphics have no child graphics, none of these subclasses implements child-related operations.
The Picture class defines an aggregate of Graphic objects. Picture implements Draw to call Draw on its children, and it implements child-related operations accordingly. Because the Picture interface conforms to the Graphic interface, Picture objects can compose other Pictures recursively.
This design pattern, as informally described above, can be seen implemented
within the Java Foundation Classes. Specifically within the Java Abstract Window
Toolkit (AWT). How this is done is presented below, and unless otherwise stated
all classes reside within the package java.awt.
java.awtSpecified in LePUS3 and Class-Z (see legend)
 |
| Composite implementation modelled in LePUS3 using 0 and 1-dimensional class (signature) constants (legend) |
|---|
 |
| Composite implementation modelled in LePUS3 using 0-dimensional class and 1-dimensional signature constants (legend) |
 |
| Composite implementation modelled in LePUS3 using 0-dimensional class and signature constants (legend) [1-dimensional signature constant CompositeOps left unexpanded for simplicity] |