Programming patterns – Composite – library MetaTrader 5

/****************************************************************
Programming patterns: Composite pattern
Compose objects into tree structures to represent part-whole hierarchies.
Composite lets clients treat individual objects and compositions of objects uniformly.
/**/

/****************************************************************/
class Component //abstract (interface)
  {
public:
   virtual void         Operation()=0;
   virtual void         Add(Component*)=0;
   virtual void         Remove(Component*)=0;
   virtual Component*   GetChild(int)=0;
                     Component() {}
                     Component(string name):mname(name)  {}
protected:
   string            mname;
  };
/****************************************************************/
class Leaf:public Component
  {
public:
   void              Operation() {Print(mname);}
   void              Add(Component*) {}
   void              Remove(Component*) {}
   Component*        GetChild(int) {return NULL;}
                     Leaf(string name):Component(name) {}
  };
/****************************************************************/
class Composite:public Component
  {
public:
   ObjectList<Component>nodes;
   void              Operation() {Print(mname); int c=nodes.Count(); for(int i=0; i<c; i++) {nodes[i].Operation();}}
   void              Add(Component*c) {nodes+=c;}
   void              Remove(Component*c) {nodes-=c;}
   Component*        GetChild(int i) {return nodes[i];}
                     Composite(string name):Component(name) {}
  };
/**/

/****************************************************************
Applicability
   Use the Composite pattern when
      you want to represent part-whole hierarchies of objects.
      you want clients to be able to ignore the difference between compositions of
       objects and individual objects. Clients will treat all objects in the composite
       structure uniformly.
Participants
   Component
      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
      represents leaf objects in the composition. A leaf has no children.
      defines behavior for primitive objects in the composition.
   Composite 
      defines behavior for components having children.
      stores child components.
      implements child-related operations in the Component interface.
   Client
       manipulates objects in the composition through the Component interface.
Collaborations
   Clients use the Component class interface to interact with objects in the
    composite structure. If the recipient is a Leaf, then the request is handled
    directly. If the recipient is a Composite, then it usually forwards requests to its
    child components, possibly performing additional operations before and/or after
    forwarding.
Consequences
   The Composite pattern
      defines class hierarchies consisting of primitive objects and composite objects.
       Primitive objects can be composed into more complex objects, which in turn can
       be composed, and so on recursively. Wherever client code expects a primitive
       object, it can also take a composite object.
      makes the client simple. Clients can treat composite structures and individual
       objects uniformly. Clients normally don't know (and shouldn't care) whether
       they're dealing with a leaf or a composite component. This simplifies client
       code, because it avoids having to write tag-and-case-statement-style functions
       over the classes that define the composition.
      makes it easier to add new kinds of components. Newly defined Composite or
       Leaf subclasses work automatically with existing structures and client code.
       Clients don't have to be changed for new Component classes.
      can make your design overly general. The disadvantage of making it easy to add
       new components is that it makes it harder to restrict the components of a
       composite. Sometimes you want a composite to have only certain components.
       With Composite, you can't rely on the type system to enforce those constraints
       for you. You'll have to use run-time checks instead.
/**/

/****************************************************************
Example of Composite pattern usage. Client
/****************************************************************/
void OnStart()
  {
   /*root*/
   Component* root=new Composite("ROOT"); //dynamic // = Composite root("ROOT"); //auto
   /*parts*/
   Component* branch1=new Composite("  Branch 1");
   Component* branch2=new Composite("  Branch 2");
   Component* leaf1=new Leaf("    Leaf 1");
   Component* leaf2=new Leaf("    Leaf 2");
   /*build tree*/
   root.Add(NULL);                        //by mistake...
   root.Add(branch1);
   root.Add(branch2);
   branch1.Add(leaf1);
   branch1.Add(leaf2);
   branch2.Add(leaf2);
   branch2.Add(new Leaf("    Leaf 3"));   //add part by reference (non-var)
   root.Operation();                      //check
     {string s; for(int i=0; i<13; i++) {s+="-";} Print(s);}
   /*remove whole branch*/
   root.Remove(branch1);
   root.Operation();                      //check
   /*delete root*/
   delete root;
  }
/****************************************************************
Output:
/**
   ROOT
     Branch 1
       Leaf 1
       Leaf 2
     Branch 2
       Leaf 2
       Leaf 3
   -------------
   ROOT
     Branch 2
       Leaf 2
       Leaf 3
/**/