Composite Pattern Implementor

When to Use

You need to model a part-whole hierarchy where clients should be able to treat leaf objects and composite objects the same way — without type-checking or branching on "is this a container or a primitive?"

Apply this skill when:

• Code that operates on a structure must repeatedly ask "is this a single item or a group?" to decide what to do — the primary code smell
• You want to represent hierarchies like: file systems (files and directories), UI trees (widgets and panels), org charts (employees and departments), document structures (characters, rows, columns), or bill-of-materials (parts and assemblies)
• A recursive containment relationship exists: containers can hold other containers as well as primitives
• New kinds of components should be addable without changing client traversal code

Two applicability conditions (from GoF):

1. You want to represent part-whole hierarchies of objects
2. You want clients to be able to ignore the difference between compositions of objects and individual objects — clients will treat all objects in the composite structure uniformly

Before starting, confirm you are not looking for Decorator (which adds responsibilities to a single object, not a tree), or Iterator (which traverses but does not define the containment structure).