Composite pattern

In software engineering, the composite pattern is a partitioning design pattern. The composite pattern describes a group of objects that are treated the same way as a single instance of the same type of object. The intent of a composite is to "compose" objects into tree structures to represent part-whole hierarchies. Implementing the composite pattern lets clients treat individual objects and compositions uniformly.

Overview
The Composite design pattern is one of the twenty-three well-known GoF design patterns that describe how to solve recurring design problems to design flexible and reusable object-oriented software, that is, objects that are easier to implement, change, test, and reuse.

What problems can the Composite design pattern solve?

 * A part-whole hierarchy should be represented so that clients can treat part and whole objects uniformly.
 * A part-whole hierarchy should be represented as tree structure.

When defining (1)  objects and (2)   objects that act as containers for   objects, clients must treat them separately, which complicates client code.

What solution does the Composite design pattern describe?

 * Define a unified  interface for both part  objects and whole  objects.
 * Individual  objects implement the   interface directly, and   objects forward requests to their child components.

This enables clients to work through the  interface to treat   and   objects uniformly: objects perform a request directly, and  objects forward the request to their child components recursively downwards the tree structure. This makes client classes easier to implement, change, test, and reuse.

See also the UML class and object diagram below.

Motivation
When dealing with Tree-structured data, programmers often have to discriminate between a leaf-node and a branch. This makes code more complex, and therefore, more error prone. The solution is an interface that allows treating complex and primitive objects uniformly. In object-oriented programming, a composite is an object designed as a composition of one-or-more similar objects, all exhibiting similar functionality. This is known as a "has-a" relationship between objects. The key concept is that you can manipulate a single instance of the object just as you would manipulate a group of them. The operations you can perform on all the composite objects often have a least common denominator relationship. For example, if defining a system to portray grouped shapes on a screen, it would be useful to define resizing a group of shapes to have the same effect (in some sense) as resizing a single shape.

When to use
Composite should be used when clients ignore the difference between compositions of objects and individual objects. If programmers find that they are using multiple objects in the same way, and often have nearly identical code to handle each of them, then composite is a good choice; it is less complex in this situation to treat primitives and composites as homogeneous.

UML class and object diagram


In the above UML class diagram, the  class doesn't refer to the   and   classes directly (separately). Instead, the  refers to the common   interface and can treat   and   uniformly. The  class has no children and implements the   interface directly. The  class maintains a container of child objects and forwards requests to these.

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


 * Defining Child-Related Operations

There are two design variants for defining and implementing child-related operations like adding/removing a child component to/from the container and accessing a child component :
 * Design for uniformity: Child-related operations are defined in the  interface. This enables clients to treat   and   objects uniformly. But type safety is lost because clients can perform child-related operations on   objects.
 * Design for type safety: Child-related operations are defined only in the  class. Clients must treat   and   objects differently. But type safety is gained because clients cannot perform child-related operations on   objects.

The Composite design pattern emphasizes uniformity over type safety.

UML class diagram



 * 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



Variation
As it is described in Design Patterns, the pattern also involves including the child-manipulation methods in the main Component interface, not just the Composite subclass. More recent descriptions sometimes omit these methods.

Example
This C++14 implementation is based on the pre C++98 implementation in the book.

The program output is