//+------------------------------------------------------------------+
//|                                               TemplateMethod.mq5 |
//|                                    2019-2020, dimitri pecheritsa |
//|                                                 792112@gmail.com |
//+------------------------------------------------------------------+
//
//   template method - behavioral design pattern
//
//   from: design patterns: elements of reusable object-oriented software
//   by gof: erich gamma, richard helm, ralph johnson, john vlissides
//   published in 1994
//
//   intent
//   
//   define the skeleton of an algorithm in an operation, deferring some 
//steps to subclasses. template method lets subclasses redefine certain 
//steps of an algorithm without changing the algorithm's structure
//
//   structure
//      
//                  |    AbstractClass     |
//                  |----------------------|
//                  |TemplateMethod()      |
//                  | ...                  |
//                  | PrimitiveOperation1()|
//                  | ...                  |
//                  | PrimitiveOperation2()|
//                  | ...                  |
//                  |PrimitiveOperation1() |
//                  |PrimitiveOperation2() |
//                             ^
//                             |
//                  |    ConcreteClass    |
//                  |---------------------|
//                  |PrimitiveOperation1()|
//                  |PrimitiveOperation2()|
//      
//   applicability
//
//   the template method pattern should be used
//      to implement the invariant parts of an algorithm once and leave 
//it up to subclasses to implement the behavior that can vary
//      when common behavior among subclasses should be factored and 
//localized in a common class to avoid code duplication. this is a good 
//example of "refactoring to generalize". you first identify the differences 
//in the existing code and then separate the differences into new operations. 
//finally, you replace the differing code with a template method that 
//calls one of these new operations
//      to control subclasses extensions. you can define a template method 
//that calls "hook" operations (see consequences) at specific points, 
//thereby permitting extensions only at those points
//
//   participants
//
//   abstract class 
//      defines abstract primitive operations that concrete subclasses 
//define to implement steps of an algorithm
//      implements a template method defining the skeleton of an algorithm. 
//the template method calls primitive operations as well as operations 
//defined in abstract class or those of other objects
//   concrete class 
//      implements the primitive operations to carry out subclass-specific 
//steps of the algorithm
//
//   collaborations
//
//   concrete class relies on abstract class to implement the invariant 
//steps of the algorithm
//
//+------------------------------------------------------------------+
//|                                              example of a client |
//+------------------------------------------------------------------+
#include <Mqh\Patterns\Template Method\AbstractClass.mqh>
#include <Mqh\Patterns\Template Method\ConcreteClass.mqh>
void OnStart()
  {
   AbstractClass* instance=new ConcreteClass();
   instance.TemplateMethod();
   delete instance;
  }
//
//   output
//
//   abstract template method requested
//   executing concrete primitive operation 1
//   executing concrete primitive operation 2
//   
//   consequences
//
//   template methods are a fundamental technique for code reuse. they 
//are particularly important in class libraries, because they are the 
//means for factoring out common behavior in library classes.
//   template methods lead to an inverted control structure that's sometimes 
//referred to as "the hollywood principle," that is, "don't call us, we'll 
//call you". this refers to how a parent class calls the operations of 
//a subclass and not the other way around.
//   template methods call the following kinds of operations:
//      concrete operations (either on the concrete class or on client 
//classes);
//      concrete abstract class operations (i.e., operations that are 
//generally useful to subclasses);
//      primitive operations (i.e., abstract operations);
//      factory methods and
//      hook operations, which provide default behavior that subclasses 
//can extend if necessary. a hook operation often does nothing by default
//
//   implementation
//
//   three implementation issues are worth noting:
//      using c++ access control
//         in c++, the primitive operations that a template method calls 
//can be declared protected members. this ensures that they are only called 
//by the template method. primitive operations that must be overridden 
//are declared pure virtual. the template method itself should not be 
//overridden; therefore you can make the template method a nonvirtual 
//member function. 
//      minimizing primitive operations
//         an important goal in designing template methods is to minimize 
//the number of primitive operations that a subclass must override to 
//flesh out the algorithm. the more operations that need overriding, the 
//more tedious things get for clients.
//      naming conventions
//         you can identify the operations that should be overridden by 
//adding a prefix to their names. for example, refix template method names 
//with "do-": "docreatedocument", "doread", and so forth.
//
//   related patterns
//
//   factory methods are often called by template methods
//   strategy: template methods use inheritance to vary part of an algorithm. 
//strategies use delegation to vary the entire algorithm
//
//+------------------------------------------------------------------+