Composite
Composite gives leaves and containers a common operation so a client can work with one item or a whole tree uniformly.
What you’ll understand
- Composite gives leaves and containers a common operation so a client can work with one item or a whole tree uniformly.
- Files return their own size; folders sum the same size operation over their children.
- Evaluate the tradeoff: Uniform operations simplify tree traversal, but some operations do not make sense for both leaves and containers. Define ownership and reject cycles if the domain permits arbitrary linking.
Useful first: Classes and Objects
The idea and when to recognize it
Composite gives leaves and containers a common operation so a client can work with one item or a whole tree uniformly.
- Requirement: A storage report needs the total size of files inside nested folders.
- Change to anticipate: Count every nested file without requiring the caller to know the folder depth.
- Design goal: Files return their own size; folders sum the same size operation over their children.
Start with the concrete problem
A storage report needs the total size of files inside nested folders.
Count every nested file without requiring the caller to know the folder depth.
| Direct implementation | Revised design |
|---|---|
| Summing only immediate files omits data inside nested folders. | Files return their own size; folders sum the same size operation over their children. |
| The baseline case can hide the problem. Compare the extension and boundary fixtures before accepting this design. | Uniform operations simplify tree traversal, but some operations do not make sense for both leaves and containers. Define ownership and reject cycles if the domain permits arbitrary linking. |
Responsibilities and contracts
Files return their own size; folders sum the same size operation over their children.
- Component: Defines a uniform size query. Public operations: size()
- File: Returns a leaf size. Public operations: size()
- Folder: Sums child components. Public operations: size()
Read the design
Select a participant to inspect its responsibility and public operations. Follow the labeled relationships; an arrow indicates direction, while the legend distinguishes ownership, substitution, and temporary use.
Preparing the design walkthrough…
Follow the interaction
Choose a supplied workload and compare the direct and revised implementations. Step through the same operation in both languages. Object values are recorded after each highlighted statement; previous steps remain unchanged.
Preparing the design walkthrough…
Implementation and expected output
Read the complete example alongside its input and expected output. The implementation selector changes the displayed program; the language selector preserves your current scenario and playback position.
Preparing the design walkthrough…
Try the idea in another setting
A user-interface container can lay out both simple widgets and nested containers through one component contract.
- Name the new client contract before adapting the example.
- Identify which state belongs to each object and who controls its lifetime.
- Write one normal case and one boundary case before extending the design.
Tradeoffs and interview takeaways
Uniform operations simplify tree traversal, but some operations do not make sense for both leaves and containers. Define ownership and reject cycles if the domain permits arbitrary linking.
Common mistake: Summing only immediate files omits data inside nested folders.
- Explain the choice: Files return their own size; folders sum the same size operation over their children.
- Challenge your choice: Uniform operations simplify tree traversal, but some operations do not make sense for both leaves and containers. Define ownership and reject cycles if the domain permits arbitrary linking.
- Describe a requirement that would make the simpler implementation sufficient.
Design challenge and knowledge check
Preparing the design walkthrough…