The Composite Design Pattern represents part–whole hierarchies as trees while giving individual objects and compositions a common interface. Clients can therefore process either kind uniformly. section 14.0 section 14.2.3
A cost-report application initially separates leaf classes such as Ball and Glove from group classes such as EquipmentGroup and UniformGroup. CostReport must receive each group separately, compute each subtotal explicitly, and understand the hierarchy. section 14.2.2
The refactoring makes ProvisionGroup a subclass of ProvisionItem. Both leaves and composites then expose operations such as cost, print_item, add, and remove; unsupported leaf operations raise an invalid-operation exception, while groups implement them. section 14.2.3
A Composite implementation typically organizes the hierarchy around these roles:
- Component: ProvisionItem defines shared properties and operations. section 14.2.4
- Leaf: Ball, Bat, Glove, Cap, Jersey, Pants, Socks, Shoes, and Sunscreen represent individual objects. section 14.2.4
- Composite: ProvisionGroup stores child ProvisionItem objects and computes its cost by summing their costs. section 14.2.3 section 14.2.4
- Client: CostReport receives one tree root and asks it to print itself, without distinguishing leaves from groups. section 14.2.3
Baseball provisions cost tree
A PROVISIONS root contains EQUIPMENT, UNIFORM, and sunscreen. UNIFORM contains FOOTWEAR, allowing the same recursive reporting operation to print item costs, group subtotals, and the $200 overall total. section 14.2 section 14.2.3
Figure 14.4 The hierarchy of objects in a tree data structure that represents the provisions for a baseball player and the cost of each item. The composite objects are shaded gray.
Inspect the hierarchy showing individual provision items, composite groups, and their part–whole relationships. section 14.2
