Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.
When complex structures are translated into object-oriented models the Composite design pattern is likely to be useful. The following are some examples.
The GHJV description of Composite puts methods for adding, removing, and accessing children in Component. In most contexts that is going overboard on uniformity of the interface. If a client needs to manipulate children it will usually know that it is dealing with a composite rather than a leaf. Consider a GUI component-container hierarchy for example. When dealing with a GUI there are usually two kinds of clients-component relationships: those in which the client knows what kind of components it is dealing with and those in which the client wants to deal with its components in a uniform way. Some clients may participate in both kinds of relationship.
For example, main programs and their helper methods involved in constructing the GUI know precisely what kind of components that they are dealing with and will only try to add a component to a container.
The internal parts of a GUI toolkit that handle event delivery and painting of the user interface usually expect a uniform interface. They will invoke methods of the top-level component through its component interface, expecting that containers will do any necessary forwarding to their children. This fowarding is an essential part of the Composite pattern implementation.
Layout managers deal with some components through their container interface and some though their component interface. A layout maneger knows that the component that it is laying out is a container. They will communicate with it through its container interface. On the other hand, a layout manager will deal with the components that are added to the container through their component interface.
This illustrates an important point: when designing a toolkit or framework it helps to do a use case analysis. Try to identify types of clients and how they will use the toolkit or framework classes. This not only improves the design, it can be used to organize the documentation. Wouldn't it be nice, for example, if class documentation divided up methods into groups according to what kinds of clients need the methods and for what purpose?