3 Combining Object Tree and Composite

The Professional Description Composition pattern is a structural design pattern that you can use to compose objects into a tree-like structure and use them as if they were independent objects.

Real-World Analogies Most countries' militaries are managed hierarchically. Each unit consists of several divisions, which are made up of brigades, which are made up of regiments, which can be further divided into platoons. In the end, each platoon consists of a small group of actual soldiers. Military orders are given at the highest level and passed through each hierarchy until each soldier knows what he should obey.

Combination Pattern Structure

  1. The Component interface describes operations common to both simple and complex items in the tree.

  2. Leaf node (Leaf) is the basic structure of the tree, it does not contain sub-items.

  • In general, leaf nodes end up doing most of the actual work because they cannot assign work to other parts.
  1. A Container - aka "Composite" - is a unit that contains sub-items such as leaf nodes or other containers. The container is unaware of the concrete class its sub-items belong to, it only interacts with its sub-items through a common component interface.
  • After the container receives the request, it will distribute the work to its own subprojects, process the intermediate results, and then return the final result to the client.
  1. Client (Client) interacts with all projects through the component interface. Thus, clients can interact in the same way with simple or complex items in the tree structure.

Example of combined mode process:

In this example, we will help you implement a series of geometries in the graphics editor with the help of the composition mode.

CompoundGraphic CompoundGraphic is a container, which can be composed of multiple sub-graphics including the container. Composite graphics have the same methods as simple graphics. However, composite graphs don't do the job by themselves, they pass requests recursively to their own subprojects and "aggregate" the results.

Client code can interact with all graphics through an interface common to all graphics classes. Therefore, the client does not know whether it is interacting with a simple graph or a composite graph. Clients can interact with very complex object structures without being tightly coupled with the entity classes that make up the structure.

Combination mode applicable scenarios:

  • If you need to implement a tree-like object structure, you can use the composition pattern.
  • Use this pattern if you want client code to handle simple and complex elements the same way.

Implementation

  1. Make sure that the core model of the application can be represented in a tree structure. Try to break it down into simple elements and containers. Remember, a container must be able to contain both simple elements and other containers.

  2. Declare a component interface and its set of methods that make sense for both simple and complex elements.

  3. Create a leaf node class to represent simple elements. There can be multiple different leaf node classes in a program.

  4. Create a container class to represent complex elements. In this class, create an array member variable to store references to its child elements. The array must be able to hold both leaf nodes and containers, so be sure to declare it as a composite interface type.
    When implementing component interface methods, keep in mind that the container should delegate most of the work to its children.

  5. Finally, define methods for adding and removing child elements in the container.
    Remember, these operations can be declared in the component interface. This would violate the _interface segregation principle_ because these methods in the leaf class are empty. However, this allows clients to access all elements indiscriminately, even those that make up a tree structure.

Code sample:

#include <algorithm>
#include <iostream>
#include <list>
#include <string>
/**
 * The base Component class declares common operations for both simple and
 * complex objects of a composition.
 */
class Component {
  /**
   * @var Component
   */
 protected:
  Component *parent_;
  /**
   * Optionally, the base Component can declare an interface for setting and
   * accessing a parent of the component in a tree structure. It can also
   * provide some default implementation for these methods.
   */
 public:
  virtual ~Component() {}
  void SetParent(Component *parent) {
    this->parent_ = parent;
  }
  Component *GetParent() const {
    return this->parent_;
  }
  /**
   * In some cases, it would be beneficial to define the child-management
   * operations right in the base Component class. This way, you won't need to
   * expose any concrete component classes to the client code, even during the
   * object tree assembly. The downside is that these methods will be empty for
   * the leaf-level components.
   */
  virtual void Add(Component *component) {}
  virtual void Remove(Component *component) {}
  /**
   * You can provide a method that lets the client code figure out whether a
   * component can bear children.
   */
  virtual bool IsComposite() const {
    return false;
  }
  /**
   * The base Component may implement some default behavior or leave it to
   * concrete classes (by declaring the method containing the behavior as
   * "abstract").
   */
  virtual std::string Operation() const = 0;
};
/**
 * The Leaf class represents the end objects of a composition. A leaf can't have
 * any children.
 *
 * Usually, it's the Leaf objects that do the actual work, whereas Composite
 * objects only delegate to their sub-components.
 */
class Leaf : public Component {
 public:
  std::string Operation() const override {
    return "Leaf";
  }
};
/**
 * The Composite class represents the complex components that may have children.
 * Usually, the Composite objects delegate the actual work to their children and
 * then "sum-up" the result.
 */
class Composite : public Component {
  /**
   * @var \SplObjectStorage
   */
 protected:
  std::list<Component *> children_;

 public:
  /**
   * A composite object can add or remove other components (both simple or
   * complex) to or from its child list.
   */
  void Add(Component *component) override {
    this->children_.push_back(component);
    component->SetParent(this);
  }
  /**
   * Have in mind that this method removes the pointer to the list but doesn't
   * frees the
   *     memory, you should do it manually or better use smart pointers.
   */
  void Remove(Component *component) override {
    children_.remove(component);
    component->SetParent(nullptr);
  }
  bool IsComposite() const override {
    return true;
  }
  /**
   * The Composite executes its primary logic in a particular way. It traverses
   * recursively through all its children, collecting and summing their results.
   * Since the composite's children pass these calls to their children and so
   * forth, the whole object tree is traversed as a result.
   */
  std::string Operation() const override {
    std::string result;
    for (const Component *c : children_) {
      if (c == children_.back()) {
        result += c->Operation();
      } else {
        result += c->Operation() + "+";
      }
    }
    return "Branch(" + result + ")";
  }
};
/**
 * The client code works with all of the components via the base interface.
 */
void ClientCode(Component *component) {
  // ...
  std::cout << "RESULT: " << component->Operation();
  // ...
}

/**
 * Thanks to the fact that the child-management operations are declared in the
 * base Component class, the client code can work with any component, simple or
 * complex, without depending on their concrete classes.
 */
void ClientCode2(Component *component1, Component *component2) {
  // ...
  if (component1->IsComposite()) {
    component1->Add(component2);
  }
  std::cout << "RESULT: " << component1->Operation();
  // ...
}

/**
 * This way the client code can support the simple leaf components...
 */

int main() {
  Component *simple = new Leaf;
  std::cout << "Client: I've got a simple component:\n";
  ClientCode(simple);
  std::cout << "\n\n";
  /**
   * ...as well as the complex composites.
   */

  Component *tree = new Composite;
  Component *branch1 = new Composite;

  Component *leaf_1 = new Leaf;
  Component *leaf_2 = new Leaf;
  Component *leaf_3 = new Leaf;
  
  branch1->Add(leaf_1);
  branch1->Add(leaf_2);
  Component *branch2 = new Composite;
  branch2->Add(leaf_3);
  
  tree->Add(branch1);
  tree->Add(branch2);
  std::cout << "Client: Now I've got a composite tree:\n";
  
  ClientCode(tree);
  std::cout << "\n\n";

  std::cout << "Client: I don't need to check the components classes even when managing the tree:\n";
  ClientCode2(tree, simple);
  std::cout << "\n";

  delete simple;
  delete tree;
  delete branch1;
  delete branch2;
  delete leaf_1;
  delete leaf_2;
  delete leaf_3;

  return 0;
}

output:

Client: I've got a simple component:
RESULT: Leaf

Client: Now I've got a composite tree:
RESULT: Branch(Branch(Leaf+Leaf)+Branch(Leaf))

Client: I don't need to check the components classes even when managing the tree:
RESULT: Branch(Branch(Leaf+Leaf)+Branch(Leaf)+Leaf)

Tags: Design Pattern

Posted by Phoenix~Fire on Thu, 05 May 2022 21:48:30 +0300