> For the complete documentation index, see [llms.txt](https://hanfak.gitbook.io/workspace/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hanfak.gitbook.io/workspace/general-paradigms/patterns/gangoffour/composite.md).

# Composite Design Pattern

## What

* meant to allow treating individual objects and compositions of objects, or “composites” in the same way.
* is a partitioning design pattern and describes a group of objects that is treated the same way as a single instance of the same type of object
* lets you compose objects into tree structures and then work with these structures as if they were individual objects.
* It can be viewed as a tree structure made up of types that inherit a base type, and it can represent a single part or a whole hierarchy of objects.
  * component
    * is the base interface for all the objects in the composition. It should be either an interface or an abstract class with the common methods to manage the child composites.
  * leaf
    * implements the default behavior of the base component. It doesn't contain a reference to the other objects.
  * composite/container
    * has leaf elements. It implements the base component methods and defines the child-related operations.
    * is an element that has sub-elements: leaves or other containers.
    * Upon receiving a request, a container delegates the work to its sub-elements, processes intermediate results and then returns the final result to the client.
  * client
    * has access to the composition elements by using the base component object.

      \-

## When to use

* when the core model of your app can be represented as a tree.
* when you want the client code to treat both simple and complex elements uniformly.
* when clients need to ignore the difference between compositions of objects and individual objects.
* find that they are using multiple objects in the same way, and often have nearly identical code to handle each of them, then composite is a good choice, it is less complex in this situation to treat primitives and composites as homogeneous.

## Advantages

* You can work with complex tree structures more conveniently: use polymorphism and recursion to your advantage
* You can introduce new element types into the app without breaking the existing code, which now works with the object tree.

## Drawbacks

* It might be difficult to provide a common interface for classes whose functionality differs too much. In certain scenarios, you’d need to overgeneralize the component interface, making it harder to comprehend.

## Comparisons with other patterns

* You can use Builder when creating complex Composite trees because you can program its construction steps to work recursively.
* Chain of Responsibility is often used in conjunction with Composite.
  * In this case, when a leaf component gets a request, it may pass it through the chain of all of the parent components down to the root of the object tree.
* You can use Iterators to traverse Composite trees.
* You can use Visitor to execute an operation over an entire Composite tree.
* You can implement shared leaf nodes of the Composite tree as Flyweights to save some RAM
* Composite and Decorator have similar structure diagrams since both rely on recursive composition to organize an open-ended number of objects.
  * A Decorator is like a Composite but only has one child component. There’s another significant difference: Decorator adds additional responsibilities to the wrapped object, while Composite just “sums up” its children’s results.
  * the patterns can also cooperate: you can use Decorator to extend the behavior of a specific object in the Composite tree.
* Designs that make heavy use of Composite and Decorator can often benefit from using Prototype. Applying the pattern lets you clone complex structures instead of re-constructing them from scratch.