Composite
Consequences
The Composite pattern
-
defines class hierarchies consisting of primitive objects
and composite objects. Primitive objects can be composed into more
complex objects, which in turn can be composed, and so on recursively.
Wherever client code expects a primitive object, it can also take a
composite object.
-
makes the client simple.
Clients can treat composite structures and individual objects
uniformly. Clients normally don't know (and shouldn't care) whether
they're dealing with a leaf or a composite component. This simplifies
client code, because it avoids having to write
tag-and-case-statement-style functions over the classes that define
the composition.
-
makes it easier to add new kinds of components.
Newly defined Composite or Leaf subclasses work automatically with
existing structures and client code. Clients don't have to be changed
for new Component classes.
-
can make your design overly general.
The disadvantage of making it easy to add new components is that it
makes it harder to restrict the components of a composite. Sometimes
you want a composite to have only certain components. With
Composite, you can't rely on the type system to enforce those
constraints for you. You'll have to use run-time checks instead.