Composite Pattern

1. What Is It?

The Composite pattern lets you compose objects into tree structures to represent part-whole hierarchies. The core insight is that clients can treat individual objects (leaves) and compositions of objects (composites) uniformly through a single interface — no type-checking required.

Without it, client code must constantly ask "is this a leaf or a container?" before acting on an object. This conditional logic scatters throughout the codebase, breaks Open/Closed, and makes adding new component types painful.

2. How It Works

Participants:

• Component — interface (or abstract class) declaring operations common to both leaves and composites (e.g., render(), getPrice())
• Leaf — a concrete component with no children; implements the Component interface directly
• Composite — a concrete component that has children (a list of Components); implements Component by delegating to its children and optionally adding its own logic
• Client — works with all components through the Component interface, never distinguishing leaf from composite

Step-by-step:

1. Define the Component interface with the operation(s) both leaves and composites must support
2. Implement Leaf — no children, just the operation
3. Implement Composite — holds a list of Component children; its operation iterates children and aggregates results
4. Client code calls component.operation() on the root — the tree recurses naturally

-+ResetFullscreen

Python:

Copy
from abc import ABC, abstractmethod
from typing import List


class PriceComponent(ABC):
    @abstractmethod
    def get_price(self) -> float:
        pass


class Item(PriceComponent):
    def __init__(self, name: str, price: float) -> None:
        self._name = name
        self._price = price

    def get_price(self) -> float:
        return self._price

    def __repr__(self) -> str:
        return f"Item({self._name}, ${self._price:.2f})"


class Bundle(PriceComponent):
    def __init__(self, name: str) -> None:
        self._name = name
        self._children: List[PriceComponent] = []

    def add(self, component: PriceComponent) -> None:
        self._children.append(component)

    def remove(self, component: PriceComponent) -> None:
        self._children.remove(component)

    def get_price(self) -> float:
        return sum(child.get_price() for child in self._children)

    def __repr__(self) -> str:
        return f"Bundle({self._name}, ${self.get_price():.2f})"


# Usage — client treats Item and Bundle identically
laptop = Item("Laptop", 999.99)
mouse = Item("Mouse", 29.99)
keyboard = Item("Keyboard", 79.99)

peripherals = Bundle("Peripherals")
peripherals.add(mouse)
peripherals.add(keyboard)

workstation = Bundle("Workstation Bundle")
workstation.add(laptop)
workstation.add(peripherals)

print(workstation.get_price())  # 1109.97 — recurses transparently

Java:

Copy
import java.util.ArrayList;
import java.util.List;

// Component
public interface PriceComponent {
    double getPrice();
}

// Leaf
public class Item implements PriceComponent {
    private final String name;
    private final double price;

    public Item(String name, double price) {
        this.name = name;
        this.price = price;
    }

    @Override
    public double getPrice() {
        return price;
    }
}

// Composite
public class Bundle implements PriceComponent {
    private final String name;
    private final List<PriceComponent> children = new ArrayList<>();

    public Bundle(String name) {
        this.name = name;
    }

    public void add(PriceComponent component) {
        children.add(component);
    }

    public void remove(PriceComponent component) {
        children.remove(component);
    }

    @Override
    public double getPrice() {
        return children.stream()
                .mapToDouble(PriceComponent::getPrice)
                .sum();
    }
}

// Client
public class ShoppingCart {
    public double calculateTotal(PriceComponent component) {
        return component.getPrice();  // works for both Item and Bundle
    }

    public static void main(String[] args) {
        Item laptop = new Item("Laptop", 999.99);
        Item mouse = new Item("Mouse", 29.99);
        Item keyboard = new Item("Keyboard", 79.99);

        Bundle peripherals = new Bundle("Peripherals");
        peripherals.add(mouse);
        peripherals.add(keyboard);

        Bundle workstation = new Bundle("Workstation Bundle");
        workstation.add(laptop);
        workstation.add(peripherals);

        ShoppingCart cart = new ShoppingCart();
        System.out.println(cart.calculateTotal(workstation)); // 1109.97
    }
}

3. Variants & Comparisons

Transparency vs. Safety variants:

The GoF book uses the transparent variant. Most modern codebases lean safe (e.g., avoid UnsupportedOperationException on leaves).

Composite vs. Decorator: Both involve a component interface wrapping other components. Composite is about tree hierarchies and aggregation; Decorator is about adding behavior to a single object. A Composite has many children; a Decorator wraps exactly one.

4. When to Use It (and When NOT To)

Use when:

• You have a tree-shaped hierarchy (file system, UI component tree, org chart, bill of materials)
• Clients should not need to distinguish between a leaf and a branch
• You want recursive operations (sum, render, serialize) to propagate naturally through the tree

Don't use when:

• The hierarchy is flat or has only one level — the pattern adds unnecessary abstraction
• Components are too different to share a common interface without forcing awkward no-ops

Decision triggers:

• "I keep writing if isinstance(x, Container) before calling children" → reach for Composite
• "I need to calculate a total/size/count across a nested structure" → Composite handles this recursively

Anti-patterns:

• Putting child-management methods on the Component when using the Safe variant defeats the purpose and causes UnsupportedOperationException surprises
• Making Composite extend Leaf — hierarchy should be from the Component interface, not from a concrete class

5. Real-World Usage

1. Java Swing / AWT UI: java.awt.Component is the Component interface. java.awt.Container is the Composite. JButton, JLabel are Leaves. JPanel is a Composite that holds other Components. Swing renders the entire UI tree by recursively calling paint() on every component — the client never cares whether it's a leaf widget or a panel.

2. HTML/DOM: Every HTML element is a node. A <div> is a Composite that holds children; a text node is a Leaf. document.getElementById("root").remove() deletes a subtree without knowing its depth.

3. java.io.File: java.io.File models both files (leaves) and directories (composites). file.listFiles() returns null for a leaf and a list for a directory — a partial Composite implementation.

6. Interview Cheat Sheet

Key sentences:

1. "Composite lets clients treat leaves and containers uniformly through a shared interface — no instanceof checks required."
2. "It's ideal when your domain naturally forms a tree: file systems, UI hierarchies, bill-of-materials, org charts."
3. "The recursive structure means operations like getPrice() or render() propagate through the tree without any orchestration code."
4. "The main trade-off is transparency vs. safety: putting add/remove on the Component interface is more uniform but forces leaves to handle operations that don't make sense for them."

Common follow-up questions:

Q: What's the difference between Composite and Decorator? A: Both wrap a Component interface, but Composite aggregates multiple children for tree structures; Decorator wraps exactly one component to add behavior.

Q: How do you handle the fact that add() doesn't make sense on a Leaf? A: Two options — Safe variant (keep add/remove on Composite only, client must cast) or Transparent variant (put them on Component with a default no-op or exception on Leaf). Safe is cleaner; Transparent is more uniform. I'd choose based on how often clients need the child-management API.

Q: Where does Composite violate LSP? A: In the Transparent variant, Leaf.add() throwing UnsupportedOperationException violates LSP — callers of the Component interface can't safely assume add() works.

Connections:

• Composite + Iterator → traverse the tree without exposing internal structure
• Composite + Visitor → add operations (e.g., serialize, validate) to a composite tree without modifying each node class
• Composite + Decorator → often appear together in UI frameworks; Composite for hierarchy, Decorator for behavior