composite

The book’s description of the Decorator Pattern is as follows:



Basically, the Composite Pattern is going to allow the programmer to write simple code that can apply the same operation (i.e. printing) over the entire menu structure. This pattern allows programmers to build structures objects in the form of trees that can contain both compositions of objects and individual objects as nodes.

Use Composite pattern when:
 * The programmer wants to represent part-whole hierarchies of objects
 * The programmer wants clients to be able to ignore the difference between compositions of objects and individual objects.

Structure of Composite Pattern
The Composite pattern has three main components. The base class that the other classes share is called the Component. This is the class with the common functionality for all classes. The Leaf is the object that makes up the individual objects that exist within the collection. The Composite is the class that forms the collection object itself. Both the leaf and the composite classes inherit from the component. This is done so that whether you call the individual leaf classes or the composite class, you still call the same method(s).



Some examples of instances where composite are useful:
 * Menus that contain menu items, each of which could be a menu.
 * Directories that contain files, each of which could be a directory.
 * Containers that contain Elements, each of which could be a Container.



- aLeaf can be any property the programmer wants it to be (size, color, year, etc). - Client will treat all objects in the composite structure uniformly.



There are two conditions to test to see if a collection of patterns is a composite pattern:

1. A relevant force between the collections of pattern interactions exists. 2. The force can be observed as a common recurring design theme throughout the patterns.





Conclusion
Using a Composite pattern is an intuitive way to define relationships between classes. It is useful in simplifying method calls when dealing with many objects in a collection. The pattern allows passed-in objects to modify overall behavior, giving a compounded effect for all the objects in the collection, as well as all underlying collections. The whole point of the Composite pattern is that the Composite can be treated atomically, just like a leaf. If the programmer wants to provide an Iterator protocol, fine, but I think that is outside the pattern itself. At the heart of this pattern is the ability for a client to perform operations on an object without needing to know that there are many objects inside.

[[image:15.jpg]]
code format="java" import java.util.ArrayList; import java.util.Iterator;

interface Movable { void operation; }

class File implements Movable { private String name;

public File(String name) { this.name = name; }

public String toString { return name; }

public void operation { System.out.println(this); } }

class FileTree extends ArrayList implements Movable { private String name;

public FileTree(String name) { this.name = name; }

public String toString { return name; }

public void operation { System.out.println(this); for (Iterator it = iterator; it.hasNext;) it.next.operation; } }

public class CompositeStructure { public static void main(String args[]) { FileTree root = new FileTree("root"); root.add(new File("Leaf1")); FileTree c2 = new FileTree("Composite1"); c2.add(new File("Leaf2")); c2.add(new File("Leaf3")); root.add(c2); c2 = new FileTree("Composite2"); c2.add(new File("Leaf4")); c2.add(new File("Leaf5")); root.add(c2); root.operation; } }

code 



Iterator ** COMPOSITE ** Proxy


 * Chapters **