# Composite

## Intent

* To "compose" objects into tree structures to represent part-whole hierarchies. Implementing the composite pattern lets clients treat individual objects and compositions **uniformly**.

## Problem

* When defining _Part_ objects and _Whole_ objects that act as containers for _Part_ objects, clients must treat them separately, which complicates client code.

## Solution

* Define a **unified** Component interface for both part _(Leaf)_ objects and whole _(Composite)_ objects.
* Individual Leaf objects implement the Component interface directly, and Composite objects forward requests to their child components.

## Advantages

✅ Simplifies client code.\
✅ Adding new component is easy.\
✅ Allows building and changing complex hierarchies dynamically at run-time.\


## Disadvantages

❌ Uniformity versus type safety.

## When to Use

* Composite should be used when clients ignore the difference between compositions of objects and individual objects. If programmers 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.

## Notes

*   The Composite design pattern emphasizes uniformity over type safety.

    * Design for uniformity
      * Child-related operations are defined in the Component interface. This enables clients to treat Leaf and Composite objects uniformly. But type safety is lost because clients can perform child-related operations on Leaf objects.
    * Design for type safety
      * Child-related operations are defined only in the Composite class. Clients must treat Leaf and Composite objects differently. But type safety is gained because clients cannot perform child-related operations on Leaf objects.

    ![Uniformity v/s Type-Safety](https://upload.wikimedia.org/wikipedia/commons/3/39/W3sDesign_Composite_Design_Pattern_Type_Safety_UML.jpg)
