Editing Composite pattern (section)

==Structure==
=== UML class and object diagram ===
[[File:w3sDesign Composite Design Pattern UML.jpg|frame|none|A sample UML class and object diagram for the Composite design pattern. <ref>{{cite web|title=The Composite design pattern - Structure and Collaboration|url=http://w3sdesign.com/?gr=s03&ugr=struct|website=w3sDesign.com|access-date=2017-08-12}}</ref>]]

In the above [[Unified Modeling Language|UML]] [[class diagram]], the <code>Client</code> class doesn't refer to the <code>Leaf</code> and <code>Composite</code> classes directly (separately).
Instead, the <code>Client</code> refers to the common <code>Component</code> interface and can treat <code>Leaf</code> and <code>Composite</code> uniformly.
<br>
The <code>Leaf</code> class has no children and implements the <code>Component</code> interface directly.
<br>
The <code>Composite</code> class maintains a container of child
<code>Component</code> objects (<code>children</code>) and forwards requests
to these <code>children</code> (<code>for each child in children: child.operation()</code>).
<br>

The object collaboration diagram 
shows the run-time interactions: In this example, the <code>Client</code> object sends a request to the top-level <code>Composite</code> object (of type <code>Component</code>) in the tree structure.
The request is forwarded to (performed on) all child <code>Component</code> objects 
(<code>Leaf</code> and <code>Composite</code> objects) downwards the tree structure.<br>

;Defining Child-Related Operations
[[File:w3sDesign Composite Design Pattern Type Safety UML.jpg|frame|none|Defining child-related operations in the Composite design pattern. <ref>{{cite web|title=The Composite design pattern - Implementation|url=http://w3sdesign.com/?gr=s03&ugr=implem|website=w3sDesign.com|access-date=2017-08-12}}</ref>]]

There are two design variants for defining and implementing child-related operations
like adding/removing a child component to/from the container (<code>add(child)/remove(child)</code>) and accessing a child component (<code>getChild()</code>):
* ''Design for uniformity:'' Child-related operations are defined in the <code>Component</code> interface. This enables clients to treat <code>Leaf</code> and <code>Composite</code> objects uniformly. But [[type safety]] is lost because clients can perform child-related operations on <code>Leaf</code> objects.
* ''Design for type safety:'' Child-related operations are defined only in the <code>Composite</code> class. Clients must treat <code>Leaf</code> and <code>Composite</code> objects differently. But type safety is gained because clients ''cannot'' perform child-related operations on <code>Leaf</code> objects.

The Composite design pattern emphasizes ''uniformity'' over ''type safety''.

=== UML class diagram ===
[[Image:Composite UML class diagram (fixed).svg|thumb|none|600px|Composite pattern in [[Unified Modeling Language|UML]].]]

;Component
* is the abstraction for all components, including composite ones
* declares the interface for objects in the composition
* (optional) defines an interface for accessing a component's parent in the recursive structure, and implements it if that's appropriate

;Leaf
* represents leaf objects in the composition
* implements all Component methods

;Composite
* represents a composite Component (component having children)
* implements methods to manipulate children
* implements all Component methods, generally by delegating them to its children

[[Image:Composite pattern in LePUS3.png|thumb|none|400px|Composite pattern in [[Lepus3|LePUS3]].]]