Composite Pattern

The Composite Pattern lets a client run one operation over a whole tree of objects by giving every node — a single object (a leaf) and a group of objects (a composite) — the same Component interface, and having each composite hold children that are themselves Components and delegate the operation to them recursively. The client calls one method on the root; polymorphism and recursion do the rest, with no instanceof checks and no special-casing for "is this a group or a single thing?".

That single idea — a container that is the same type as the things it contains — is what turns a part-whole hierarchy (files in folders, employees in departments, widgets in panels) into uniform client code.

The problem it removes

Consider a company org chart: the company holds departments, a department holds employees and can hold sub-departments, and so on to any depth. You want the total working hours under any node. Without Composite, the client must ask "is this an employee or a department?" at every step and branch accordingly — the branching leaks into every caller and multiplies with every new operation (total cost, headcount, print org chart…).

Composite pushes that branching into the objects. An Employee knows how to return its own hours; a Department knows how to sum its children's hours — and because a child might itself be a Department, the sum recurses down the tree automatically. The client just calls root.getHours().

The three roles

• Component — the common interface (or abstract class) that both leaves and composites implement. It declares the operations the client calls uniformly (here, getHours()).
• Leaf — an indivisible node with no children (Employee). It implements the operation directly.
• Composite — a node that holds a list of Component children (Department) and implements each operation by delegating to those children and combining the results.

Implementation (Java)

This is the safe variant (child management lives only on the composite — we will weigh that choice against the alternative below). It compiles and runs as-is.

Traced worked example

Calling company.getHours() triggers a depth-first recursion. Each leaf returns its own number (the base case); each composite returns the sum of what its children returned. Reading the trace bottom-up shows the totals bubbling to the root:

Notice the client wrote none of this arithmetic and never asked what type any node was — the recursion and the shared interface carried it.

The key design decision: where does add(child) live?

This is the interview question on Composite, and naming the choice is the whole answer. The add/remove/getChild methods only make sense on a composite — a leaf has nowhere to put a child. So where do you declare them?

Transparent — child ops in the Component interface

Declare add/remove on Component itself. Now a client holding a Component reference never needs to know whether it is a leaf or a composite — the interface is identical for both. This is maximum uniformity, which is the pattern's whole reason to exist.

The cost: Employee (a leaf) now inherits an add method that is meaningless for it. It has to do something, and the only honest thing is to fail:

interface OrganizationComponent {
    String getName();
    int getHours();
    void add(OrganizationComponent c);      // meaningful only on composites
    void remove(OrganizationComponent c);
}

class Employee implements OrganizationComponent {
    // getName(), getHours() as before ...
    @Override public void add(OrganizationComponent c) {
        throw new UnsupportedOperationException("A leaf employee cannot hold children");
    }
    @Override public void remove(OrganizationComponent c) {
        throw new UnsupportedOperationException("A leaf employee cannot hold children");
    }
}

So employee.add(x) compiles fine and explodes at runtime. The safety violation is real but deferred — the type system can no longer catch it. This is the design the Gang of Four (GoF) recommends: they explicitly favor transparency, accepting the runtime risk because uniform treatment is the point of the pattern.

Safe — child ops only on the Composite

Declare add/remove only on Department (the variant in the code above). Now it is impossible to call add on a leaf — there is no such method, so the compiler rejects it. No runtime surprise.

The cost: a client that wants to add a child must know it is holding a Department, which means a downcast or type check — exactly the "what type is this node?" branching Composite set out to eliminate:

OrganizationComponent node = registry.get("Development");
if (node instanceof Department dept) {   // client must distinguish types again
    dept.add(new Employee("Raj", 25));
}

Naming the trade-off

It is transparency vs type-safety:

• Transparent = one uniform interface, client never type-checks — but illegal calls (leaf add) can only fail at runtime.
• Safe = illegal calls are a compile error — but the client must distinguish leaves from composites, giving up the uniformity that motivated the pattern.

GoF picks transparency. Pick safety when the tree is assembled in controlled construction code where the downcast is localized to one place (a builder/factory) and the client that reads the tree still only sees the uniform getHours(). In an interview: state which you chose and why — that sentence is what the question is testing.

Pitfalls

• The leaf-throws tax. In the transparent design, forgetting that leaf.add() throws is a classic bug. Document it and, if the operation is optional, let the client probe with an isComposite() method rather than catching exceptions for control flow.
• Cycles. Nothing in the pattern stops you from adding an ancestor as a child (dev.add(company)). That makes the "tree" a cyclic graph, and getHours() recurses forever until a StackOverflowError. If untrusted code builds the tree, guard add against introducing a cycle.
• Parent references. If you add an upward parent pointer (handy for "what department is this employee in?"), add and remove must keep it in sync, and re-parenting a node must detach it from its old parent first — otherwise a node appears under two parents and totals double-count.
• Deep recursion & recompute cost. getHours() uses call-stack depth equal to the tree depth; a pathologically deep tree can overflow the stack (switch to an explicit stack/iteration if depth is unbounded). Also, each call re-walks the whole subtree — O(n) per query. If totals are read hot and the tree changes rarely, cache the subtotal on each composite and invalidate up the parent chain on mutation.

When to use it — and when not

Use Composite when you have a genuine part-whole hierarchy and clients should apply the same operation to a single item and a group without caring which they hold. The tells: a recursive "X contains Xs" structure (folders, menus, GUI widget trees, ASTs, org charts) plus operations that make sense at every level.

Do not use it when the collection is flat (a plain List is simpler — Composite's value is the recursion), or when leaves and composites have genuinely different operations that will not unify. Forcing a shared interface onto types that do not want one is over-generalization: the interface fills with methods that half the implementers reject.

Versus named alternatives

• vs a plain nested List<Object>. A nested list can also hold a tree, but the client must instanceof-check and branch at every node to know whether to recurse. Composite replaces that branching with polymorphism — each node knows how to handle itself. Choose the raw list only for a one-off traversal where writing a class hierarchy is not worth it.
• vs Decorator. Both are recursive-composition patterns with the same "hold a Component" shape, which is why they are confused. The difference is arity and intent: a Decorator wraps exactly one child to add responsibilities (behavior layering); a Composite holds many children to represent a hierarchy (structure). Reach for Decorator to stack behavior, Composite to model a tree. They compose cleanly — a decorated node can sit anywhere in a composite tree.

Takeaways

• Composite is recursion made polymorphic: the composite is the same type as its children and delegates to them, so client code has one path for a leaf and a whole tree.
• The design decision is where child management lives. Transparent (in Component — uniform, runtime risk) vs safe (on the composite only — type-checked, client must downcast). GoF favors transparency; always state your choice and its cost.
• Guard the tree: keep it acyclic, keep parent pointers in sync, and watch recursion depth and per-query recompute cost on large or hot trees.
• Only for real hierarchies. A flat list, or Decorator for behavior layering, is often the better fit — Composite earns its keep when the structure is genuinely recursive.

Sources: Gamma, Helm, Johnson & Vlissides, Design Patterns (Gang of Four) — the transparency-vs-safety discussion; Freeman & Robson, Head First Design Patterns; refactoring.guru (Composite). Re-authored/Deepened for this guide.