complete Composite Pattern

Author: tk-codes

StructuralPatterns/Composite/README.md

@@ -1,6 +1,6 @@
 # Composite Pattern
 
-The intent of composite pattern is to *compose* objects into tree structures to represent part-whole hierarchies.
+The intent of composite pattern is to *compose* objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.
 
 ## Problem
 
@@ -12,10 +12,35 @@ The intent of composite pattern is to *compose* objects into tree structures to
 * Define a unified `Component` interface for both part (`Leaf`) objects and whole (`Composite`) objects.
 * Individual `Leaf` objects implement the `Component` interface directly, and `Composite` objects forward requests to their child components.
 
+## Common Structure
+
+![Common structure of composite pattern](https://upload.wikimedia.org/wikipedia/commons/6/65/W3sDesign_Composite_Design_Pattern_UML.jpg)
+
+* Component (IFileSystemComponent)
+  * declares an interface for objects in the composition.
+  * implements default behaviour for the interface common to all classes, as appropriate.
+* Leaf (File)
+  * A leaf has no children.
+  * defines behavior for primitive objects in the composition.
+* Composite (Folder)
+  * stores child components
+  * defines/implements behaviour for components having children.
+* Client (FileSystem)
+  * manipulates objects in the composition through the Component interface.
+
+## Collaboration
+
+* Clients use the Component class interface to interact with objects in the composite structure.
+    * If the recipient is a Leaf, then the request is handled directly.
+    * If the recipient is a Composite, then it usually forwards requests to its child components, possibly performing additional operations before and/or after forwarding.
+
 ## Benefits
 
-* We can apply the same operations over both composites and individual objects (leaves).
+* Makes the client simple.
+  * It can apply the same operations over both composites and individual objects (leaves).
 * In most cases we can ignore the differences between the composition of objects and leaves.
+* Makes it easier to add new kinds of components
+  * Newly defined Composite or Leaf subclasses work automatically with existing structures and client code.
 
 ## Drawbacks
 
@@ -106,20 +131,10 @@ Output
          File 1 in Main Folder
 ```
 
-## Common Structure
-
-![Common structure of composite pattern](https://upload.wikimedia.org/wikipedia/commons/6/65/W3sDesign_Composite_Design_Pattern_UML.jpg)
-
-* Component (IFileSystemComponent)
-  * declares an interface for objects in the composition.
-  * implements default behaviour for the interface common to all classes, as appropriate.
-* Leaf (File)
-  * A leaf has no children.
-  * defines behavior for primitive objects in the composition.
-* Composite (Folder)
-  * stores child components
-  * defines/implements behaviour for components having children.
-* Client (FileSystem)
-  * manipulates objects in the composition through the Component interface.
+## Relations with Other Patterns
 
-_[Source: http://www.dofactory.com/net/composite-design-pattern]_
+* **Chain of Responsibility** - Often the component-parent link is used for a Chain of Responsibility.
+* **Decorator** is often used with Composite. When decorators and composites are used together, they will usually have a common parent class. So decorators will have to support the Component interface with operations like Add, Remove, and GetChild.
+* **Flyweight** lets you share components, but they can no longer refer to their parents.
+* **Iterator** can be used to traverse composites.
+* **Visitor** localizes operations and behavior that would otherwise be distributed across Composite and Leaf classes.