The Composite pattern allows clients to treat both individual components and groups of components uniformly by composing objects into tree structures. It allows clients to call operations on individual leaf nodes or composite nodes that then propagate the call to child nodes, resulting in recursive behavior without clients needing to know the structure's composition. The pattern uses an abstract component class that defines common behavior for both simple and composite components, with composite classes containing and managing child components.

1. Composite Design Pattern
The 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
quot;childrenquot; 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, quot;childrenquot;, 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.