Composite Design Pattern in Java: Explanation and Example

A gaming storefront lists ten leaf game titles and three genre folders, then wants to print every title for under twenty dollars. The first implementation spreads conditionals everywhere: “if this item is a folder, iterate; if it is a title, check its price.” The discount logic now knows about the tree, the rendering logic knows about the tree, and the next feature that needs the same traversal will duplicate that knowledge a third time. When a designer nests a genre inside another genre, two of those traversals break.

The Composite design pattern in Java removes that branching by treating single objects and object groups through the same interface. A leaf title and a composite genre both answer listGames() and addGame(), so client code can call a folder exactly as it calls a title and let polymorphic dispatch manage the recursion. This guide expands the pattern from intent to trade-offs, and if you have not yet compared how other structural patterns tame interfaces, read Adapter Design Pattern in Java: Explanation and Example for bridging granularity before diving into recursive composition.

Table of Contents

What Is the Composite Pattern?

Composite is a structural Gang of Four pattern whose intent is to compose objects into tree structures that represent part-whole hierarchies and let clients treat individual objects and compositions uniformly. The trick is not tree building itself, which any developer can code with lists. The trick is unifying the access path so a leaf and a composite look identical to every consumer that calls them.

Consider the file system. Both a plain file and a folder expose getSize() and printTree(int indent). A file computes size trivially, a folder aggregates over children and delegates printing. Caller code never asks “are you a file or a folder,” which is why adding a nested folder does not ripple through the printing, size, and search routines. The pattern captures that discipline as a formal relationship.

A frequent misunderstanding is to equate composite with the word composition in everyday Java. Composition as an OO principle means an object holds references to other objects. Composite is a stricter enhancement that pairs composition with inheritance from a shared component interface so the composition itself can be treated as if it were a leaf. Without that shared interface, every consumer carries instanceof checks that quietly make complexity linear in the number of call sites instead of concentrated in the tree nodes.

Why Composite Exists: The Uniform Treatment Problem

Hierarchies appear wherever a domain catalog is naturally nested. A gaming company ships PC games, Sport Games, and Racing Games, each containing titles that share the catalog operation “list your contents.” An e-commerce site has categories and products with “apply discount.” A build system has files and folders with “resolve dependencies.” In each case, product code wants to say catalog.listGames() without caring whether the receiver is a single genre or a root genre containing genres.

Without composite, logic fractures. Discount logic must say “if this node is composite, iterate children; otherwise handle the leaf.” Logging logic must repeat the same test, and metrics collection must repeat it again. Every leaf-versus-group variance leaks into business code, which means a change to the tree shape is not a change to one class but a change to every feature touching the tree. Reviewers also stop trusting the catalog model because the contract “this is hierarchical” is not encoded anywhere other than the collaborator’s documentation.

Composite solves this by pushing the traversal knowledge down. The component interface declares the catalog operations. Leaf overrides with direct behavior. Composite holds a collection of components, delegates child-management operations like addGame, and implements operations by aggregating over children while recursively asking each child to do the same. Callers above the tree then degenerate into a one-liner: obtain the root component and call the operation. Depth of nesting stops being a caller concern. This also clarifies why the pattern excels in UI frameworks, where a toolkit must lay out panels inside panels inside windows through the same paint() and add() surface without each panel knowing how deeply it is nested.

Participants: Component, Leaf, Composite, Client

Component is the abstraction that defines the shared operations for both leaf and composite. In the gaming example, Games declares listGames(), addGame(Games), and removeGame(Games). WHY declare both hierarchy management and business operations in one interface? Because the caller benefit is precisely that one interface can be passed around as if it were always a single title. In the transparent variant, both operation kinds live on the component so consumers never need to downcast.

Leaf is the terminal node that holds no children. GameTitle stores a title name and price, prints itself in listGames(), and responds to child-management methods by throwing UnsupportedOperationException. WHY throw rather than no-op? Because silently ignoring addGame() would hide a domain error such as adding a title to another title. Being explicit turns it into a fast failure during development, which is what you want for incorrect tree assembly.

Composite is the internal node that holds children. GameGenre keeps a List<Games> for both leaves and nested genres, implements addGame() and removeGame() by delegating to that list, and implements listGames() by iterating and recursively asking each child to list itself. WHY implement listGames() as a recursive dispatch rather than flattening into a list? So that each level can inject its own behavior such as printing the genre name before its children, applying a sort order, or reacting to an iteration exception with try/finally logic confined to its subtree.

Client operates solely through the component. The gaming client’s main obtains a Games reference, assembles a tree via addGame, and calls listGames() on the root. It passes no instanceof test and never imports GameGenre or GameTitle beyond construction helpers. That decoupling is the signal that the pattern is being honored. If the client started branching on if (game instanceof GameGenre), the composite’s value has already been surrendered.

Transparent vs Safe Variants

Two modeling variants are worth distinguishing, because interviews surface them quickly.

Transparent declares child-management methods on the component so leaf and composite share the exact same type. Callers can always call addGame on any Games object without a cast, and leaf corrects misuse by throwing. Transparent composition maximizes uniformity. It is the variant most UI toolkits like java.awt.Container use, and the variant this tutorial’s example follows.

Safe declares child-management methods only on the composite so leaf does not carry operations it cannot satisfy, which keeps leaf types small and prevents runtime exceptions. The cost is that callers that do tree assembly must know whether they hold a composite and cast or guard appropriately. That discrimination reintroduces the caller knowledge that composite is trying to eliminate.

Choice hinges on call-site frequency. If most callers only consume the tree through leaf-sense operations like listGames, transparent composition gives the cleanest consumption path while isolating assembly-time guard checks to the few callers that build the tree. If misuse of leaf child operations has historically caused data integrity issues in the catalog, safe composition earns its caller branching by preventing the exception category entirely. Most catalogs with frequent nesting choose transparent because assembly sites are few while consuming sites are many.

Mermaid Structure Diagram

flowchart TD
    CL[Client\nassembles & invokes root] --> C[Component\nGames]
    C --> L[Leaf\nGameTitle\nprice + name]
    C --> COMP[Composite\nGameGenre\nList Games]
    COMP --> CH1[Child 1\nLeaf GameTitle]
    COMP --> CH2[Child 2\nComposite GameGenre]
    CH2 --> GC1[Grandchild\nGameTitle]
    CH2 --> GC2[Grandchild\nGameTitle]
    L --> OP[listGames\nleaf behavior]
    COMP --> Agg[Aggregates\nforEach Games::listGames]
    Agg --> CL
    CH1 --> OP
    GC1 --> OP
    GC2 --> OP

    classDef component fill:#e1f5fe,stroke:#01579b,stroke-width:2px,color:#000000;
    classDef leaf fill:#f3e5f5,stroke:#4a148c,stroke-width:2px,color:#000000;
    classDef composite fill:#fff3e0,stroke:#e65100,stroke-width:2px,color:#000000;
    classDef client fill:#e8f5e9,stroke:#1b5e20,stroke-width:2px,color:#000000;
    class C component;
    class L,CH1,GC1,GC2,OP leaf;
    class COMP,CH2,Agg composite;
    class CL client;

The recursion loop is explicit. A composite delegates to children that may themselves be composites, which makes the rounded rectangle of uniform invocation visible even though depth grows arbitrarily. Nesting like PC Games -> Sport Games -> FIFA 19 requires no new client code.

Real-World Code Example: Gaming Catalogue Tree

The gaming company needs a catalogue that can represent standalone titles like Sims 3, nested genres like Sport Games inside PC Games, and future nesting that marketing will invent as new collections appear. Every catalogue operation must work regardless of shape.

Component: The Shared Catalogue Contract

package com.adevguide.java.designpatterns.composite;

// WHY: abstract class carries shared state like name so leaves and composites reuse the identity field
public abstract class Games {

    private String name;

    public Games(String name) {
        // WHY: validate once centrally so no catalog entry has a blank display label
        if (name == null || name.isBlank()) {
            throw new IllegalArgumentException("Game or genre name must be non-blank");
        }
        this.name = name;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        if (name == null || name.isBlank()) {
            throw new IllegalArgumentException("Name must be non-blank");
        }
        this.name = name;
    }

    // WHY: both display and hierarchy operations share the component so callers can treat leaves and genres alike
    public abstract void listGames();
    public abstract void addGame(Games game);
    public abstract void removeGame(Games game);
}

Leaf: A Title That Cannot Hold Children

package com.adevguide.java.designpatterns.composite;

public class GameTitle extends Games {

    private int price; // WHY: keep per-title state localized so composites stay purely structural

    public GameTitle(String name, int price) {
        super(name);
        if (price < 0) {
            throw new IllegalArgumentException("Price cannot be negative");
        }
        this.price = price;
    }

    public int getPrice() {
        return price;
    }

    public void setPrice(int price) {
        if (price < 0) throw new IllegalArgumentException("Price cannot be negative");
        this.price = price;
    }

    @Override
    public void listGames() {
        System.out.println(getName() + " is available for " + getPrice() + "$");
    }

    @Override
    public void addGame(Games game) {
        // WHY: fail fast so callers cannot build a degenerate title-under-title tree silently
        throw new UnsupportedOperationException("Cannot add a game to a leaf title: " + getName());
    }

    @Override
    public void removeGame(Games game) {
        throw new UnsupportedOperationException("Cannot remove a game from a leaf title: " + getName());
    }
}

Composite: A Genre That Aggregates Children

package com.adevguide.java.designpatterns.composite;

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

public class GameGenre extends Games {

    // WHY: composite holds abstractions so genres can contain titles and other genres
    private final List<Games> gameList = new ArrayList<>();

    public GameGenre(String name) {
        super(name);
    }

    @Override
    public void listGames() {
        System.out.println(getName());
        // WHY: try/finally would belong here if listing touched an external resource like a file listing
        // so each subtree can release its own iterator even if a child fails mid-print
        for (Games g : gameList) {
            g.listGames();
        }
    }

    @Override
    public void addGame(Games game) {
        // WHY: requireNonNull guards against deferred NullPointerException during listGames traversal
        this.gameList.add(java.util.Objects.requireNonNull(game, "game must not be null"));
    }

    @Override
    public void removeGame(Games game) {
        this.gameList.remove(game);
    }

    // WHY: a secondary traversal like averagePrice would follow the same recursive shape
    // so pricing policies need not know about the tree either
    public double averagePrice() {
        if (gameList.isEmpty()) return 0;
        int sum = 0; int leaves = 0;
        for (Games g : gameList) {
            if (g instanceof GameTitle) {
                sum += ((GameTitle) g).getPrice();
                leaves++;
            } else if (g instanceof GameGenre) {
                // WHY: recursion keeps aggregation logic inside composite, not in the consumer
                sum += ((GameGenre) g).averagePrice() * countLeaves((GameGenre) g);
                leaves += countLeaves((GameGenre) g);
            }
        }
        return leaves == 0 ? 0 : (double) sum / leaves;
    }

    private int countLeaves(GameGenre genre) {
        int c = 0;
        for (Games g : genre.gameList) {
            if (g instanceof GameTitle) c++;
            else if (g instanceof GameGenre) c += countLeaves((GameGenre) g);
        }
        return c;
    }
}

Notice why averagePrice is shown even though it uses instanceof. The first composite role, recursive display, can be fully uniform through listGames(). A second aggregation that needs per-leaf values sometimes requires type knowledge if the component did not model getPrice() uniformly. That downstream tension explains why some composite designs add methods like getPrice() to the component and have composites aggregate while leaves return their own value, which removes the second branching but expands the component interface. The right choice depends on how many uniform traversals the catalogue actually supports, not how pure the hierarchy looks in isolation.

Client That Treats Single and Group Uniformly

package com.adevguide.java.designpatterns.composite;

public class Client {

    public static void main(String[] args) {

        final String SEPARATOR = "**********************************";
        Games gameType = new GameGenre("PC Games");

        gameType.addGame(createMiscGame());
        gameType.listGames();
        System.out.println(SEPARATOR);

        gameType.addGame(createSportGames());
        gameType.listGames();
        System.out.println(SEPARATOR);

        gameType.addGame(createRacingGames());
        gameType.listGames();
        System.out.println(SEPARATOR);

        // WHY: after the tree is assembled, consumer code holds only Games references
        // so later feature like discounted listing can iterate uniformly without catalog knowledge
        System.out.println("All titles under 10 dollars:");
        listCheapTitles(gameType, 10);
    }

    private static Games createSportGames() {
        Games sportGames = new GameGenre("Sport Games");
        Games fifa = new GameTitle("FIFA 19", 10);
        Games nba = new GameTitle("NBA 2K19", 6);
        sportGames.addGame(fifa);
        sportGames.addGame(nba);
        return sportGames;
    }

    private static Games createRacingGames() {
        Games racingGames = new GameGenre("Racing Games");
        Games nfs = new GameTitle("Need For Speed", 15);
        Games realRacing = new GameTitle("Real Racing", 5);
        racingGames.addGame(nfs);
        racingGames.addGame(realRacing);
        return racingGames;
    }

    private static Games createMiscGame() {
        // WHY: returns Games, not GameTitle, so caller cannot accidentally special-case misc handling
        return new GameTitle("Sims 3", 1);
    }

    private static void listCheapTitles(Games node, int threshold) {
        // WHY: true uniform treatment would be a Component method; this helper shows the branching fallback
        // when the component does not expose price uniformly and client must branch once in a utility
        if (node instanceof GameTitle) {
            GameTitle title = (GameTitle) node;
            if (title.getPrice() < threshold) title.listGames();
        } else if (node instanceof GameGenre) {
            // reflection via listGames is visual; a real filter would recurse or use visitor
            // keeping branching isolated here is acceptable if the catalog exposes visitor instead of bloating component
            GameGenre genre = (GameGenre) node;
            // Not traversing internals here in demo; real uniform filtering belongs inside composite as a method
        }
    }
}

Output:

PC Games
Sims 3 is available for 1$
**********************************
PC Games
Sims 3 is available for 1$
Sport Games
FIFA 19 is available for 10$
NBA 2K19 is available for 6$
**********************************
PC Games
Sims 3 is available for 1$
Sport Games
FIFA 19 is available for 10$
NBA 2K19 is available for 6$
Racing Games
Need For Speed is available for 15$
Real Racing is available for 5$
**********************************
All titles under 10 dollars:

The instructive passage is how main assembles three shapes and invokes listGames() on the same gameType reference each time. Once that line is uniform, a new nested genre from marketing slots in without touching the consumer. That property is why composite improves velocity long after the first demo. The listCheapTitles fragment is deliberately left incomplete to make the design point concrete. When a catalog gains a second or third uniform query beyond display, adding methods like filterByPrice() or a visitor to the component eliminates that one branched helper entirely, which is the real-world fork where transparent composite expands.

Real-World Example: How Google Drive, Babel, and Swing Use Composite

Google Drive and Dropbox folder models. Both the file browser and the permission layer recursively treat a document and a folder as a single kind of node. When a user shares a folder, the permission traversal applies the same share operation to every descendant without the sharing handler learning recursion. Drive’s REST resources model this explicitly with a files collection where a file’s mimeType distinguishes folder from document, but the server handler that copies or trash-bins a node treats both via a unified operation. The business reason to model this as a composite rather than ad-hoc recursion is concurrency. A folder permission change must apply uniformly to newly created descendants that arrive while the traversal is in flight. A composite with a single code path for application makes that atomicity reasoning localized.

Babel AST and compiler IR. Babel parses JavaScript into an abstract syntax tree where a Program contains FunctionDeclaration nodes that contain BlockStatement nodes that contain expression nodes. Node visitors for transforms traverse the tree by asking each node to visit its children with the same interface. A plugin that converts arrow functions to function expressions handles a Program and a BlockStatement uniformly because both implement the node storage contract. The performance consequence at compiler scale is direct. One visitor infrastructure replaces per-node-type traversal logic in dozens of plugins, which is the difference between a maintainable transform pipeline and a fragile one where every plugin reimplements child iteration.

java.awt.Container and Swing. java.awt.Container#add(Component) is the canonical JDK composite. A Container is itself a Component, so it can be added to another container. Layout, paint, and event propagation recurse through the same call surface whether the receiver is a JButton leaf or a JPanel composite with fifty descendants. Production teams still see this directly when bridging Swing panels with adapter-style wrappers around legacy widgets. Amazon’s internal Swing tooling and Eclipse’s UI editor both leverage the composite depth to let editor plugins treat a deeply nested dock pane the same way as a top-level window, proving that the pattern survives well beyond textbook examples.

When to Use vs When NOT to Use

Use Composite when:

• The domain is inherently hierarchical and every caller should treat a single item and a group similarly. A catalogue, an org hierarchy, or a scene graph that must support arbitrary nesting justifies the tree contract.

• Multiple consumers need the same traversal shape. When listing, pricing, permission checking, and export all want to walk the same subtree, unifying traversal once inside the composite prevents repetition that would otherwise accumulate across features.

• Uniform operations outnumber tree assembly operations. If display and aggregation dominate and tree building is rare, transparent composite is the right blend because consuming code reaps the greatest benefit from uniformity.

Do NOT use Composite when:

• The structure is flat or depth is permanently one. A list of games without genres should remain a list. Forcing a composite grammar around one level adds indirection and makes queries like SELECT * harder to translate into a tree.

• Leaf and composite operations are fundamentally incompatible. If a leaf supports applyDiscount(double) but a composite must support applyDiscount(DiscountPolicy, Set<GameTitle>) with different parameters, unifying them under one interface muddles the semantics. Keep separate types and accept caller branching or introduce a visitor that dispatches correctly.

• Leaf order or type restrictions are domain invariants that composite cannot naturally enforce. A tournament bracket that allows exactly two children per node, or a file system that must forbid folders inside files at compile time, may benefit from a typed algebraic data type or dedicated safe-composite constraints rather than a permissive List<Games> that accepts any shape and relies on runtime validation.

If your broader architecture is deciding between wrapping an incompatible interface versus unifying a tree walk, framing the choice as adapter for external mismatch and composite for internal recursion, with bridge or decorator for orthogonal concerns, keeps the structural section of the system design whiteboard honest. The creational companion to this decision is covered by Abstract Factory Pattern in Java: Explanation and Example and Factory Design Pattern Java Simplified, which show when grouping creation is more valuable than grouping consumption.

Advantages and Trade-offs

Composite makes adding a new node or genre trivial because addition is just constructing a node and appending it to a parent composite. Aggregation moves into the composite once, so business code never calculates sums or collects leaves with a manual queue. This supports the Open-Closed Principle for catalogue growth: new titles extend the data shape while consuming code does not change.

The price is abstraction dilution and runtime discovery of errors that a type system would have caught. Transparent composites carry child-management methods on leaf, which violates strict type honesty and hides misuse until UnsupportedOperationException appears in production logs from a mis-wired builder helper. Safe composites fix honesty by restricting leaf types but push an instanceof or visitor back into the few callers that assemble trees, so the design shifts which consumer pays. Every composite hierarchy also pays for indirection when traversed depth-first, and cache locality degrades for very wide, shallow trees where a flat indexed collection plus LINQ-style filters would be measurably faster.

Test discipline matters for the same reason as construction is handled in Builder Design Pattern Java Real World Example: a deep tree built with one wrong child silently produces correct-length output that contains the wrong descendant count. Catalogue builders deserve factory helpers like createSportGames() that encode valid composition, paired with tests that assert shape counts rather than just string output, which prevents regressions when marketers rename genres but keep the count stable.

Common Pitfalls

Masking a graph cycle as a tree. Composite models trees, not arbitrary graphs. When an entity like a shared DLC pack appears under two genres as the same GameTitle instance, mutating its price from under one composite changes the visible price under the other, and naive recursive printing would print the same leaf twice. Detect this by making GameTitle effectively immutable after construction, cloning shared leaves if reuse is intentional, or defining that catalogue ownership is composition-like and a game may belong to one genre unless explicitly modeled as a reference. Logging tree shape at debug level during ingestion helps catch accidental cycles before they reach consumers.

Violating the component contract by assuming order. Consumers that index into gameList.get(1) or depend on insertion order as semantic meaning couple themselves to assembly detail. If a sort-by-price feature reorders children to improve rendering, those index assumptions silently break discount logic. Treat Composite children as an ordered view only when ordering is a documented part of the contract, and otherwise iterate via the public listGames() contract rather than poking the backing list through an added getter that exposes internal structure.

Escalating into god composite by adding every query to the component. Teams that successfully unify listGames() become eager and add getPrice(), getReleaseDate(), applyDiscount(), and exportToPdf() to Games. The composite quickly becomes a bloated interface that leaves must stub with exceptions and that complicates code review. When the tenth query arrives and it diverges from the display concern, model the query as a visitor instead of another component method so traversal stays uniform without polluting leaf. Visitor pairs naturally with composite because the composite holds the recursion while the visitor holds the per-node strategy.

Interview Questions

1. What problem does the Composite pattern solve and how does it complement the file-system mental model?

Composite addresses the uniform treatment problem where otherwise identical operations are implemented twice, once for a single object and once for a group. By introducing a shared component interface, client code like “print everything in this genre” never distinguishes a title from a folder. The file-system mental model clarifies roles: files are leaves that know their own size, folders are composites that aggregate over children, and both answer print() and add() through the same interface. That uniformity is WHY nesting depth stops being a client concern and WHY new depth from product management requires no client change, which is the pattern’s practical deliverable beyond code neatness.

2. Explain the trade-off between transparent and safe implementations.

Transparent declares child-management methods on the component so any Games node can be treated uniformly and leaf corrects misuse by throwing UnsupportedOperationException. This makes consumption elegant because a handler typed as Games never branches, but it allows a logical error to survive until runtime if someone adds a title to another title. Safe declares child operations only on the composite, so leaf types remain honest and cannot mistakenly expose addGame, at the cost of requiring callers that build the tree to know they hold a composite and cast or guard appropriately. Most production catalogues choose transparent because consuming sites vastly outnumber assembly sites, and assembly-time mistakes are cheaper to catch in tree-builder helper tests.

3. Where does the JDK use Composite, and how would you prove familiarity with the API?

The classic answer is java.awt.Container#add(Component). A Container extends Component, so containers nest arbitrarily and layout, painting, and event dispatch recurse uniformly through Component. Swing builds on the same contract, which is WHY a deeply nested dock panel and a top-level window render through identical calls. Call getComponents() on a container to observe the children stored as Component[], confirming the composite shared supertype. A second strong example is the File system contract in NIO.2 where visiting a tree with Files.walkFileTree composes recursively even though File itself is not packaged as a leaf type in the example, but Component in AWT is the interview-ready citation.

4. How does Composite relate to Decorator, Adapter, and Visitor?

Decorator adds behavior to the same interface without changing the tree shape. Adapter bridges an incompatible interface pair so one subsystem can call another. Composite treats a single object and a group uniformly through a shared interface so recursion becomes polymorphic. Visitor pairs specifically well with composite when uniform consumption must grow to many query shapes. Leaf and composite hold the recursive walk, while visitors hold per-node behavior like pricing, filtering, or exporting. If you merge visitor and composite carelessly, you invert traversal control. Composite should invoke the visitor per node rather than having the visitor reimplement traversal, which keeps depth responsibility and iteration policy co-located with the tree.

5. How do you prevent composite cycles and which invariants matter in production?

Cycles arise when a node added under itself through a descendant creates infinite recursion in listGames() and a stack overflow in production under a deeper-than-typical catalogue. Defend with three invariants: immutable leaf state after construction so a shared subtree cannot be mutated from under a second parent, defensive cycle detection at addGame time by walking ancestors before attaching a child, and integration tests that assert leaf counts per subgenre rather than only asserting rendered strings. Where cycle validation needs resource cleanup such as closing an iterator or file walk, wrap recursive descent with try/finally so partial traversal failures do not leak handles, which is the resource corollary of the structural invariant.

6. When is Composite the wrong structural pattern for a hierarchy?

Composite is the wrong choice when the structure is inherently graph-like rather than tree-like, when leaf and composite responsibilities never align, or when type invariants must be guaranteed at compile time. A shared DLC pack owned by two genres, a leaf that supports price while a composite that supports scheduling, or a bracket that must allow exactly two children are all signals against a permissive composite. In the first case a DAG or graph model with shared references is more honest, in the second case separate types with explicit callers or a visitor keep contracts narrow, and in the third case a specialized data structure with fixed arity and its own factory, akin to patterns covered in Singleton Creational Design Pattern Java Explained, enforces correctness without runtime exceptions.

Conclusion

Composite proves its value the moment catalogue code stops branching on node kind:

1. Unify the consumption path. Declaring shared operations on the component lets callers treat a single title and a full genre tree through one interface, which localizes recursion.
2. Choose transparent or safe deliberately. Transparent favors consumer elegance with leaf-time exceptions, safe favors leaf honesty with caller branching; optimize for the common caller shape.
3. Keep composites disciplined. Validate insertion, hold children behind abstraction, and avoid adding every query to the component, because each additional method expands what leaves must fake.
4. Add visitor when queries multiply. When pricing and export queries outgrow display, let composite hold traversal and visitor hold behavior to avoid god interface drift.
5. Build trees narrowly. Centralize valid composition in factory helpers like createSportGames() so domain invariants are asserted by construction and not by auditing scattered client code.

The next topic in this series on structural patterns covers Decorator – adding responsibilities to objects dynamically – which complements composite because decorator adds orthogonal behavior to single nodes while composite groups nodes for shared traversal. For the canonical structural wrapping problem that precedes composition choices, revisit Adapter Design Pattern in Java: Explanation and Example.

References

1. Composite Pattern - Refactoring Guru
   https://refactoring.guru/design-patterns/composite
2. Composite Pattern - OODesign
   https://www.oodesign.com/composite-pattern.html
3. Composite Pattern - Baeldung
   https://www.baeldung.com/java-composite-pattern

YouTube Videos

1. “Composite Design Pattern: Easy Guide For Beginners”
   https://www.youtube.com/watch?v=ZCNQ7xsed58

2. “Composite Design Pattern in Java”
   https://www.youtube.com/watch?v=AIyTWtOqrfs

3. “Composite Design Pattern”
   https://www.youtube.com/watch?v=2HUnoKyC9l0