Intent: Compose objects into tree structures that represent whole-part hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly. A leaf has the same interface as a node.
Contrast this to the Restricted Composite Pattern discussed in Cpp Utx Overview that uses External Polymorphism so that a leaf need not inherit the collection interface needed by a node.
Comments On Composite, Dark Side Of Composite Pattern, Composite Pattern Example, Composite Considered Harmful, Interpreter Vs Composite
A leaf does not have to have the same interface as the node base-class. It typically extends the node interface with methods that are not used polymorphically. Similarly, leaves do not usually implement collection interfaces. The composite node extends the basic node class with the collection behaviour and interface. -- Anonymous Donor
Hmmm.. Well I guess it depends on which description of the Composite Pattern you follow. Are you saying that Leaf doesn't descend from Composite or that Composite doesn't define the collection interface? If we go back to the Gang Of Four Design Patterns Book, the Component class establishes an interface including Add( Component ), Remove( Component ), and GetChild( int ). The Leaf and Composite classes both descend from Component. In fact, if you go to the Participants section, the third bullet for Component states that a Component "declares an interface for accessing and managing its child components." What's optional is the fourth bullet, which are members for accessing a component's parent. What am I missing? While I prefer your comments and have always used Composite in this way, it seems to be a variation on the original Composite Pattern. -- Robert Di Falco
The Anonymous Donor is wrong, and Robert Di Falco is right. In the Design Patterns Book, we intended a Leaf to have the same interface as the base class, and for a Composite too, as well. The discussion on page 167-169 is based on that fact that it is usually impossible to make them all exactly the same, but it is worth trying. In practice, the interfaces are usually almost identical, but not quite. -- Ralph Johnson
So what's the point of trying it?? Why is it worth trying? I cannot think of an example... Even in the Unix filesystem, where directories are files, the solution is to make Composite implement the interface of Leaf... -- Euyyn at Wikipedia
I sometime use (what I guess is) a degenerate Composite Pattern in which the Leaf and Composite have the same interface as the base class, but only the Composite has the collection interface. In BNF:
<node> ::= <leafnode> | <compositenode> <compositenode> ::= <node>*
Perhaps this would be better termed a CompoundPattern rather than Composite Pattern (but this Wiki Word is already taken). Comments? -- George Dinwiddie
Right or wrong?
There are designs where the leaves should have dummy child management method, and designs where they shouldn't; structures which are not general trees or where the interface of Add( Component ), Remove( Component ), and GetChild( int ) is too free; algorithms which use parent links in the tree and algorithms which don't need them; and so on. There is a continuous space of possible solutions; the Composite as described in the Design Patterns Book is a typical example, not the only right way to define aggregates. -- Lorenzo Gatti
This just in (June 2006): Rebecca Wirfs-Brock has written an article entitled "Refreshing Patterns" in the IEEE Software Magazine (Vol 23 No 3 May/June 2006)pages 45-47. She argues that patterns need to evolve and uses the Composite Pattern as an example. Quotes one of the GoF authors... -- Richard Botting
By the way, why do we say that the Composite Pattern makes a Tree Structure? Surely we can add components that are already part of the structure? Did the GoF discuss this? Doesn't the remove method need to be a little complicated to avoid collecting garbage twice? -- Richard Botting (I've been bitten by this bug in the past. It took months to diagnose.)
Composite Pattern suggests Navigational Database / Object Oriented Database and inherits many weaknesses thereof (especially in the face of concurrency). It is worth considering alternatives. If Composite Pattern is being used to represent structured messages or values, consider use of immutable structures and functional construction (without Side Effects). If Composite Pattern is being used to represent data - such as a world-model or Scene Graph or Document Object Model - consider introducing a dedicated Data Base object, possibly one well proven to achieve both performance and flexibility, such as Relational Model.
See original on c2.com 