Variant 1: Design for Uniformity

• The only way to provide uniformity is to define child-related operations in the Component interface.
• This enables uniformity because clients can treat Leaf and Composite objects uniformly.
• But we loose type safety because Leaf and Composite interfaces (types) are not cleanly separated.
• The abstract Component class implements default behavior for child-related operations like "do nothing" or "throw an exception". The Leaf class inherits the default imple­mentations, and Composite must redefine them.
• Uniformity is useful for dynamic structures because clients often need to perform child-related operations (in a document editor, for example, where the object structure is dynamically created and changed each time a document is changed).
• The Composite design pattern emphasizes uniformity over type safety.

Variant 2: Design for Type Safety

• The only way to provide type safety is to define child-related operations solely in the Composite class.
• This enables type safety because we can rely on the type system to enforce type constraints (for example, that clients can not perform child-related operations on Leaf components).
• But we loose uniformity because clients must treat Leaf and Composite objects differently.
• Type safety is useful for static structures (that do not change very often) because most clients do not need to perform child-related operations.