Composite Design Pattern

Purpose

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

Play with an Example

Suppose we are copying a set of folders from one location to another.So that we dont need to copy/paste each file by file. Just need to select the list of folder and press ctrl+c then goto the destination location and press on ctrl+v, It will paste the completes selected folders and its childs to the destination

Lest create a program for printing the folder/file tree details. Suppose there is a set of folders and files are there, It needsto print the complete tree information with a single function.

Lets create a program for printing the details of above tree.

First lets create an interface Record which will extends with both files an folders. It contains the common functions for both files and folders

We have two types of files in the tree, which are image files and text files(In this example we are calling ImageRecord and DataRecord for these files)

Next we can create the FolderRecord. It is able to put files or another folder in a folder.

Here the main program will constricting the above mentioned tree

Points to Remember

• Ensure that your problem is about representing "whole-part" hierarchical relationships.
• Consider the heuristic, "Containers that contain containees, each of which could be a container." For example, "Assemblies that contain components, each of which could be an assembly." Divide your domain concepts into container classes, and containee classes.
• 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.
• All container and containee classes declare an "is a" relationship to the interface.
• All container classes declare a one-to-many "has a" relationship to the interface.
• Container classes leverage polymorphism to delegate to their containee objects.
• Child management methods [e.g. addChild(), removeChild()] should normally be defined in the Composite class. Unfortunately, the desire to treat Leaf and
• Composite objects uniformly may require that these methods be promoted to the abstract Component class. See the Gang of Four for a discussion of these "safety" versus "transparency" trade-offs.

Advanced Points

• Composite and Decorator have similar structure diagrams, reflecting the fact that both rely on recursive composition to organize an open-ended number of objects.
• Composite can be traversed with Iterator. Visitor can apply an operation over a Composite. Composite could use Chain of Responsibility to let components access global properties through their parent. It could also use Decorator to override these properties on parts of the composition. It could use Observer to tie one object structure to another and State to let a component change its behavior as its state changes.
• Composite can let you compose a Mediator out of smaller pieces through recursive composition.
• Decorator is designed to let you add responsibilities to objects without subclassing. Composite's focus is not on embellishment but on representation. These intents are distinct but complementary. Consequently, Composite and Decorator are often used in concert.
• Flyweight is often combined with Composite to implement shared leaf nodes.