'''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 CppUtxOverview that uses ExternalPolymorphism so that a ''leaf'' need not inherit the collection interface needed by a ''node''.

'''See also:''' VisitorPattern, HierarchicalVisitorPattern, DesignPatterns

----
CommentsOnComposite,
DarkSideOfCompositePattern,
CompositePatternExample,
CompositeConsideredHarmful,
InterpreterVsComposite
----

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. -- AnonymousDonor

Hmmm.. Well I guess it depends on which description of the CompositePattern 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 GangOfFour DesignPatternsBook, the ''Component'' class establishes an interface including ''Add( Component )'', ''Remove( Component )'', and ''Get''''''Child( 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 CompositePattern''. -- RobertDiFalco

The AnonymousDonor is wrong, and RobertDiFalco is right. In the DesignPatternsBook, 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. -- RalphJohnson

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 CompositePattern 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 Compound''''''Pattern rather than CompositePattern (but this WikiWord is already taken).  Comments? -- GeorgeDinwiddie

----

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 ''Get''''''Child( 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 DesignPatternsBook is a typical example, not the only right way to define aggregates. -- LorenzoGatti

----
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 CompositePattern as
an example. Quotes one of the GoF authors... -- RichardBotting

By the way, why do we say that the CompositePattern makes a TreeStructure? 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? -- RichardBotting (I've been bitten by this bug in the past. It took months to diagnose.)

----------

CompositePattern suggests NavigationalDatabase / ObjectOrientedDatabase and inherits many weaknesses thereof (especially in the face of concurrency). It is worth considering alternatives. If CompositePattern is being used to represent structured messages or values, consider use of immutable structures and functional construction (without SideEffect''''''s). If CompositePattern is being used to represent data - such as a world-model or SceneGraph or DocumentObjectModel - consider introducing a dedicated DataBase object, possibly one well proven to achieve both performance and flexibility, such as RelationalModel. 

----

http://home.earthlink.net/~huston2/dp/composite.html

http://wiki.cs.uiuc.edu/patternStories/CompositePattern

----
CategoryPattern | CategoryStructuralPatterns