Code documentation - Software Development Case Studies in Java - page 195

Forces or tradeoffs Composite can also be a component. Different kinds of

nodes. Ordering of different kinds of nodes is difficult.
Nodes should be seen uniformly.
Visiting of nodes can require many special cases.

Solution The following structure of classes should be adopted.

*

Component

operation() children

Leaf Composite

operation() operation()

add()

1

All the concrete leaves can be subclasses of Leaf while all
concrete composites can be subclasses of Composite .
If there is only one leaf (composite) class then the Leaf
( Composite ) class can be substituted by this class.

Force resolution It is possible to visit all the nodes of the hierarchy

seamlessly.
Node classes must conform to the common interface.
It is easy to add new kinds of nodes.
It is much easier to understand.

Design rationale This pattern results from the application of two idioms:

class generalization and relationship factoring.
It minimizes redundancy and provides a simpler and
more uniform interface to the structure.

8.9 ■ References

Gamma, E., Helm, R., Johnson, R. and Vlissides, J. (1995) Design Patterns: Elements
of Reusable Object-Oriented Software , Addison-Wesley.
W3C (2004a) HyperText Markup Language (HTML) , http://www.w3.org/MarkUp/.
W3C (2004b) Extensible Markup Language (XML) , http://www.w3.org/XML/.
W3C (2004c) Document Object Model (DOM), http://www.w3.org/DOM/.