Composite Design Pattern

http://www.dofactory.com/net/composite-design-pattern

Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.

• Component   (DrawingElement)
  • declares the interface for objects in the composition.
  • implements default behavior for the interface common to all classes, as appropriate.
  • declares an interface for accessing and managing its child components.
  • (optional) defines an interface for accessing a component's parent in the recursive structure, and implements it if that's appropriate.
• Leaf   (PrimitiveElement)
  • represents leaf objects in the composition. A leaf has no children.
  • defines behavior for primitive objects in the composition.
• Composite   (CompositeElement)
  • defines behavior for components having children.
  • stores child components.
  • implements child-related operations in the Component interface.
• Client  (CompositeApp)
  • manipulates objects in the composition through the Component interface.

http://www.tutorialspoint.com/design_pattern/composite_pattern.htm
Composite pattern is used where we need to treat a group of objects in similar way as a single object. Composite pattern composes objects in term of a tree structure to represent part as well as whole hierarchy. 

public class Employee { private List<Employee> subordinates;}

https://sourcemaking.com/design_patterns/composite

• Compose objects into tree structures to represent whole-part hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.
• Recursive composition
• "Directories contain entries, each of which could be a directory."
• 1-to-many "has a" up the "is a" hierarchy

Define an abstract base class (Component) that specifies the behavior that needs to be exercised uniformly across all primitive and composite objects. Subclass the Primitive and Composite classes off of the Component class. Each Composite object "couples" itself only to the abstract type Component as it manages its "children".

Use this pattern whenever you have "composites that contain components, each of which could be a composite".

Child management methods [e.g. addChild(), removeChild()] should normally be defined in the Composite class. Unfortunately, the desire to treat Primitives and Composites uniformly requires that these methods be moved to the abstract Component class. 

1. Create a "lowest common denominator" interface that makes your containers and containees interchangeable. It should specify the behavior that needs to be exercised uniformly across all containee and container objects.
2. All container and containee classes declare an "is a" relationship to the interface.
3. All container classes declare a one-to-many "has a" relationship to the interface.
4. Container classes leverage polymorphism to delegate to their containee objects.

Examples:

interface AbstractFile:   public void ls();

class File implements AbstractFile

class Directory implements AbstractFile