Composite Design Pattern

---

Dark Mode

Show Highlights

Audio Clips

Problem 

Software often needs to treat individual objects and nested groups of objects uniformly. File systems contain files and directories, drawing tools contain primitive shapes and grouped drawings, and menu systems contain both single menu items and complete submenus. If a client has to distinguish between every leaf and every container, the code quickly fills with special cases and repeated tree traversal logic.

Context

The Composite pattern applies when the domain is naturally recursive: a whole is built from parts, and some parts can themselves contain further parts. In such systems, clients want one common abstraction for both single objects and containers so they can issue operations like print(), render(), or totalPrice() without checking whether the receiver is a leaf or a branch.

Solution

The Composite Pattern introduces a common Component abstraction shared by both atomic elements (Leaf) and containers (Composite). The composite stores child components and forwards operations recursively to them. Clients program only against the Component interface, which keeps the traversal logic inside the structure rather than scattering it across the application.

UML Role Diagram

UML Example Diagram

Sequence Diagram

Design Decisions

Transparent vs. Safe Composite

This is the fundamental design trade-off of the Composite pattern:

• Transparent composite: The full child-management interface (add(), remove(), getChild()) is declared on Component, so clients can treat leaves and composites identically through a single interface. This maximizes uniformity but means leaves inherit methods that make no sense for them (e.g., add() on a MenuItem). Leaves must either throw an exception or silently ignore these calls.

• Safe composite: Only Composite exposes add() and remove(), preventing nonsensical operations on leaves at compile time. But clients must now distinguish between leaves and composites when managing children, reducing the pattern’s primary benefit of uniform treatment.

Neither approach is universally better—the choice depends on whether uniformity (transparent) or type safety (safe) is more important in your context.

Child Ownership

If child objects cannot exist independently of their parent, use composition semantics and let the composite own the child lifetime. If children may be shared across multiple structures, model a weaker association instead. In UML, this distinction maps to filled-diamond composition vs. open-diamond aggregation.

Parent References

Adding a parent reference to Component enables upward traversal (e.g., “which menu does this item belong to?”) but complicates add() and remove() operations, which must now maintain bidirectional consistency.

Composite in Pattern Compounds

The Composite pattern frequently appears as a building block in larger pattern compounds, because many patterns need to operate on tree structures:

• Composite + Builder: The Builder pattern can construct complex Composite structures step by step. The Composite’s Component acts as the Builder’s product, and the Builder handles the complexity of assembling the recursive tree.
• Composite + Visitor: When many distinct operations need to be performed on a Composite structure without modifying its classes, the Visitor pattern provides a clean separation of concerns. This is especially useful when new operations are added frequently but new leaf types are rare.
• Composite + Iterator: An Iterator can traverse the Composite tree in different orders (depth-first, breadth-first) without exposing the tree’s internal structure to the client.
• Composite + Command: A Composite Command groups multiple command objects into a tree, allowing hierarchical undo/redo operations and macro commands that execute sub-commands in sequence.

These compounds are so common that recognizing the Composite pattern is often the first step toward identifying a larger architectural pattern at work.

Flashcards

Structural Pattern Flashcards

Key concepts for Adapter, Composite, and Facade patterns.

What problem does Adapter solve?

Allows classes with incompatible interfaces to work together by translating one interface into another that the client expects.

Like a power outlet adapter for international travel — translates between two incompatible standards without modifying either one.

Object Adapter vs. Class Adapter?

Object Adapter uses composition (wraps the adaptee), works in any language. Class Adapter uses multiple inheritance, only in C++.

Modern consensus strongly favors Object Adapters for flexibility and compatibility with single-inheritance languages like Java.

Adapter vs. Facade vs. Decorator?

Adapter converts an interface. Facade simplifies a set of interfaces. Decorator adds behavior through the same interface.

Key: Adapter changes what the interface looks like; Facade reduces how much you see; Decorator enhances what the object does.

What does POSA5 say about ‘the Adapter pattern’?

It is actually a family of at least four patterns: Object Adapter, Class Adapter, Two-Way Adapter, and Pluggable Adapter.

When someone says ‘use the Adapter pattern,’ you must clarify which form of adaptation is needed.

What problem does Composite solve?

Treats individual objects and nested groups uniformly through a shared abstraction, eliminating special-case code for leaves vs. containers.

Clients program against the Component interface. The recursive structure lets operations work identically on single items and nested trees.

Composite: Transparent vs. Safe design?

Transparent: child-management on Component (uniform, leaves get meaningless methods). Safe: child-management only on Composite (type-safe, clients must distinguish).

Fundamental trade-off. Transparent maximizes uniformity; Safe maximizes type safety. Choice depends on context.

Name three pattern compounds involving Composite.

Composite + Builder (construct trees), Composite + Visitor (operate on trees), Composite + Iterator (traverse trees).

Composite is a natural building block for other patterns because many patterns need to operate on recursive tree structures.

What problem does Facade solve?

Provides a simplified, unified interface to a complex subsystem, reducing the number of objects a client must interact with.

The Facade handles coordination between subsystem components. Importantly, it does not ‘trap’ the subsystem — direct access remains available.

Facade vs. Mediator: what’s the communication direction?

Facade: one-directional (subsystem unaware of Facade). Mediator: bidirectional (colleagues communicate through mediator and back).

Facade simplifies. Mediator coordinates. If the intermediary just delegates, it’s a Facade. If it manages bidirectional control flow, it’s a Mediator.

Should the subsystem know about its Facade?

No. The Facade knows the subsystem, but the subsystem remains independent — it can function without the Facade.

This one-directional knowledge is a key design property. The subsystem can be used and tested independently of the Facade.

Workout Complete!

Your Score: 0/10

Come back later to improve your recall!

Quiz

Structural Patterns Quiz

Test your understanding of Adapter, Composite, and Facade — their distinctions, design decisions, and when to apply each.

A TurkeyAdapter implements the Duck interface. The fly() method calls turkey.flyShort() five times in a loop to simulate a longer flight. What design concern does this raise?

Correct Answer:

Explanation

Simple interface translation (renaming quack() to gobble()) is low-risk. But the fly() mapping introduces behavioral adaptation — the adapter contains logic (a loop) that goes beyond translating signatures. As adapters grow ‘thicker’ with more logic, they evolve from interface translators into separate service components. This is a warning sign that the adapter may be taking on too much responsibility.

A colleague says: “We should use an Adapter between our service and the database layer.” Your team wrote both the service and the database layer. What is the best response?

Correct Answer:

Explanation

The Adapter pattern is designed for after-the-fact interface mismatches — typically with third-party or legacy code you cannot modify. If you control both interfaces, there is no mismatch to adapt around. Simply refactor one interface to match the other. Adding an Adapter here would introduce unnecessary indirection. If you anticipate the interfaces diverging in the future (e.g., the database layer will be replaced), Bridge is the upfront solution.

In a Composite pattern for a restaurant menu system, a developer declares add(MenuComponent) on the abstract MenuComponent class (inherited by both Menu and MenuItem). A tester calls menuItem.add(anotherItem). What happens, and what design trade-off does this illustrate?

Correct Answer:

Explanation

This is the Transparent Composite trade-off. By putting add()/remove() on the abstract Component, clients get a uniform interface (any component can be treated the same), but leaves inherit methods that are semantically meaningless. The leaf must handle this — typically by throwing UnsupportedOperationException. The Safe Composite alternative puts these methods only on Composite, preventing the call at compile time but requiring clients to downcast.

All three patterns — Adapter, Facade, and Decorator — involve “wrapping” another object. What is the key distinction between them?

Correct Answer:

Explanation

The distinction is intent: Adapter changes what the interface looks like (converts incompatible to compatible). Facade changes how much of the interface you see (simplifies a complex subsystem). Decorator changes what the object does through the same interface (adds behavior). Understanding intent is what separates correct pattern application from cargo-cult pattern usage.

A HomeTheaterFacade exposes watchMovie(), endMovie(), listenToMusic(), stopMusic(), playGame(), setupKaraoke(), and calibrateSystem(). The class is growing difficult to maintain. What is the best architectural response?

Correct Answer:

Explanation

A single Facade wrapping a large subsystem risks becoming a god class. The solution is to create multiple focused Facades, each responsible for a different aspect of the subsystem. PlaybackFacade handles movie/music playback, SetupFacade handles karaoke and game setup, and CalibrationFacade handles system tuning. Each Facade remains cohesive and manageable.

The Facade’s communication is one-directional: the Facade calls subsystem classes, but the subsystem does not know about the Facade. The Mediator’s communication is bidirectional. Why does this distinction matter architecturally?

Correct Answer:

Explanation

Because the subsystem does not know about the Facade, it remains fully independent — usable and testable without the Facade present. In contrast, Mediator colleagues depend on the Mediator interface to communicate — they cannot function independently. This is why Facade is a convenience layer (optional), while Mediator is a coordination layer (required for the objects to interact).

Workout Complete!

Your Score: 0/6

Sample Code