Composite pattern

In software engineering, the composite pattern is a partitioning design pattern. The composite pattern describes a group of objects that is 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) Part objects and (2) Whole objects that act as containers for Part objects, clients must treat them separately, which complicates client code.

What solution does the Composite design pattern describe?

• 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.

This enables clients to work through the Component interface to treat Leaf and Composite objects uniformly: Leaf objects perform a request directly, and Composite 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.

Structure

UML class and object diagram

A sample UML class and object diagram for the Composite design pattern.

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

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

Defining Child-Related Operations

Defining child-related operations in the Composite design pattern.

There are two design variants for defining and implementing child-related operations like adding/removing a child component to/from the container (add(child)/remove(child)) and accessing a child component (getChild()):

• Design for uniformity: Child-related operations are defined in the Component interface. This enables clients to treat Leaf and Composite objects uniformly. But type safety is lost because clients can perform child-related operations on Leaf objects.
• Design for type safety: Child-related operations are defined only in the Composite class. Clients must treat Leaf and Composite objects differently. But type safety is gained because clients can not perform child-related operations on Leaf objects.

The Composite design pattern emphasizes uniformity over type safety.

UML class diagram

Composite pattern in UML.

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

Composite pattern in LePUS3.

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

The following example, written in Java, implements a graphic class, which can be either an ellipse or a composition of several graphics. Every graphic can be printed. In Backus-Naur form,

       Graphic ::= ellipse | GraphicList
       GraphicList ::= empty | Graphic GraphicList

It could be extended to implement several other shapes (rectangle, etc.) and methods (translate, etc.).

Java

/** "Component" */
interface Graphic {

    //Prints the graphic.
    public void print();
}

/** "Composite" */
class CompositeGraphic implements Graphic {

    //Collection of child graphics.
    private List<Graphic> childGraphics = new ArrayList<Graphic>();

    //Prints the graphic.
    public void print() {
        for (Graphic graphic : childGraphics) {
            graphic.print();  //Delegation
        }
    }

    //Adds the graphic to the composition.
    public void add(Graphic graphic) {
        childGraphics.add(graphic);
    }

    //Removes the graphic from the composition.
    public void remove(Graphic graphic) {
        childGraphics.remove(graphic);
    }
}

/** "Leaf" */
class Ellipse implements Graphic {

    //Prints the graphic.
    public void print() {
        System.out.println("Ellipse");
    }
}

/** Client */
public class Program {

    public static void main(String[] args) {
        //Initialize four ellipses
        Ellipse ellipse1 = new Ellipse();
        Ellipse ellipse2 = new Ellipse();
        Ellipse ellipse3 = new Ellipse();
        Ellipse ellipse4 = new Ellipse();

        //Initialize three composite graphics
        CompositeGraphic graphic = new CompositeGraphic();
        CompositeGraphic graphic1 = new CompositeGraphic();
        CompositeGraphic graphic2 = new CompositeGraphic();

        //Composes the graphics
        graphic1.add(ellipse1);
        graphic1.add(ellipse2);
        graphic1.add(ellipse3);

        graphic2.add(ellipse4);

        graphic.add(graphic1);
        graphic.add(graphic2);

        //Prints the complete graphic (Four times the string "Ellipse").
        graphic.print();
    }
}

C#

The following example, written in C#.

namespace CompositePattern
{
    using System;
    using System.Collections.Generic;
    using System.Linq;
    //Client
    class Program
    {
        static void Main(string[] args)
        {
            // initialize variables
            var compositeGraphic = new CompositeGraphic();
            var compositeGraphic1 = new CompositeGraphic();
            var compositeGraphic2 = new CompositeGraphic();

            //Add 1 Graphic to compositeGraphic1
            compositeGraphic1.Add(new Ellipse());

            //Add 2 Graphic to compositeGraphic2
            compositeGraphic2.AddRange(new Ellipse(), 
                new Ellipse());

            /*Add 1 Graphic, compositeGraphic1, and 
              compositeGraphic2 to compositeGraphic */
            compositeGraphic.AddRange(new Ellipse(), 
                compositeGraphic1, 
                compositeGraphic2);

            /*Prints the complete graphic 
            (four times the string "Ellipse").*/
            compositeGraphic.Print();
            Console.ReadLine();
        }
    }
    //Component
    public interface IGraphic
    {
        void Print();
    }
    //Leaf
    public class Ellipse : IGraphic
    {
        //Prints the graphic
    	public void Print()
        {
            Console.WriteLine("Ellipse");
        }
    }
    //Composite
    public class CompositeGraphic : IGraphic
    {
        //Collection of Graphics.
        private readonly List<IGraphic> graphics;

        //Constructor 
        public CompositeGraphic()
        {
            //initialize generic Collection(Composition)
            graphics = new List<IGraphic>();
        }
        //Adds the graphic to the composition
        public void Add(IGraphic graphic)
        {
            graphics.Add(graphic);
        }
        //Adds multiple graphics to the composition
        public void AddRange(params IGraphic[] graphic)
        {
            graphics.AddRange(graphic);
        }
        //Removes the graphic from the composition
        public void Delete(IGraphic graphic)
        {
            graphics.Remove(graphic);
        }
        //Prints the graphic.
        public void Print()
        {
            foreach (var childGraphic in graphics)
            {
                childGraphic.Print();
            }
        }
    }
}
//////Ad

Simple example

/// Treats elements as composition of one or more elements, so that components can be separated
/// between one another
public interface IComposite
{
    void CompositeMethod();
}

public class LeafComposite :IComposite 
{
    public void CompositeMethod()
    {
        //To Do something
    }
}

/// Elements from IComposite can be separated from others 
public class NormalComposite : IComposite
{
    public void CompositeMethod()
    {
        //To Do Something
    }

    public void DoSomethingMore()
    {
        //Do Something more.
    }
}

Crystal

abstract class Graphic
  abstract def print
end

# Composite
class CompositeGraphic < Graphic
  private getter graphics

  def initialize
    @graphics = [] of Graphic
  end

  def print
    @graphics.each do |graphic|
      graphic.print
    end
  end

  def add(graphic : Graphic)
    @graphics.push(graphic)
  end

  def remove(graphic : Graphic)
    @graphics.delete(graphic)
  end
end

# Leaf
class Ellipse < Graphic
  private getter name : String

  def initialize(@name)
  end

  def print
    puts "Ellipse #{name}"
  end
end

class Program
  def initialize
    ellipse1 = Ellipse.new("1")
    ellipse2 = Ellipse.new("2")
    ellipse3 = Ellipse.new("3")
    ellipse4 = Ellipse.new("4")

    graphic = CompositeGraphic.new
    graphic1 = CompositeGraphic.new
    graphic2 = CompositeGraphic.new

    # graphic 1 contains 3 ellipses
    graphic1.add(ellipse1)
    graphic1.add(ellipse2)
    graphic1.add(ellipse3)

    # graphic 2 contains 1 ellipse
    graphic2.add(ellipse4)

    # graphic contains both graphic 1 and graphic 2
    graphic.add(graphic1)
    graphic.add(graphic2)

    # now print the graphic
    graphic.print
  end
end

Program.new

Python

"""
Composite pattern example.
"""
from abc import ABC, abstractmethod

NOT_IMPLEMENTED = "You should implement this."


class Graphic(ABC):
    @abstractmethod
    def print(self):
        raise NotImplementedError(NOT_IMPLEMENTED)


class CompositeGraphic(Graphic):
    def __init__(self):
        self.graphics = []

    def print(self):
        for graphic in self.graphics:
            graphic.print()

    def add(self, graphic):
        self.graphics.append(graphic)

    def remove(self, graphic):
        self.graphics.remove(graphic)


class Ellipse(Graphic):
    def __init__(self, name):
        self.name = name

    def print(self):
        print("Ellipse:", self.name)


ellipse1 = Ellipse("1")
ellipse2 = Ellipse("2")
ellipse3 = Ellipse("3")
ellipse4 = Ellipse("4")

graphic = CompositeGraphic()
graphic1 = CompositeGraphic()
graphic2 = CompositeGraphic()

graphic1.add(ellipse1)
graphic1.add(ellipse2)
graphic1.add(ellipse3)

graphic2.add(ellipse4)

graphic.add(graphic1)
graphic.add(graphic2)

graphic.print()

See also

• Perl Design Patterns Book
• Mixin
• Law of Demeter

External links

• Composite Pattern implementation in Java
• Composite pattern description from the Portland Pattern Repository
• Composite pattern in UML and in LePUS3, a formal modelling language
• Class::Delegation on CPAN
• "The End of Inheritance: Automatic Run-time Interface Building for Aggregated Objects" by Paul Baranowski
• PerfectJPattern Open Source Project, Provides componentized implementation of the Composite Pattern in Java
• [1] A persistent Java-based implementation
• Composite Design Pattern