//+------------------------------------------------------------------+
//| Strategy.mq5 |
//| 2019-2020, dimitri pecheritsa |
//| 792112@gmail.com |
//+------------------------------------------------------------------+
//
// strategy - 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 a family of algorithms, encapsulate each one, and make them
//interchangeable. strategy lets the algorithm vary independently from
//clients that use it
//
// applicability
//
// many related classes differ only in their behavior. strategies provide
//a way to configure a class with one of many behaviors
// you need different variants of an algorithm. for example, you might
//define algorithms reflecting different space/time trade-offs. strategies
//can be used when these variants are implemented as a class hierarchy
//of algorithms
// an algorithm uses data that clients shouldn't know about. use the
//strategy pattern to avoid exposing complex, algorithm-specific data
//structures
// a class defines many behaviors, and these appear as multiple conditional
//statements in its operations. instead of many conditionals, move related
//conditional branches into their own strategy class
//
// structure
//
// strategy
// | Context |o-------->| Strategy |
// |------------------| |--------------------|
// |ContextInterface()| |AlgorithmInterface()|
// ^
// |
// +------------------------+----------------------+
// | | |
// | ConcreteStrategyA | | ConcreteStrategyB | | ConcreteStrategyC |
// |--------------------| |--------------------| |--------------------|
// |AlgorithmInterface()| |AlgorithmInterface()| |AlgorithmInterface()|
//
//
// participants
//
// strategy
// declares an interface common to all supported algorithms. context
//uses this interface to call the algorithm defined by a concrete strategy
// concrete strategy
// implements the algorithm using the strategy interface
// context
// is configured with a concrete strategy object
// maintains a reference to a strategy object
// may define an interface that lets strategy access its data
//
// collaborations
//
// strategy and context interact to implement the chosen algorithm.
//a context may pass all data required by the algorithm to the strategy
//when the algorithm is called. alternatively, the context can pass itself
//as an argument to strategy operations. that lets the strategy call back
//on the context as required
// a context forwards requests from its clients to its strategy. clients
//usually create and pass a concrete strategy object to the context;
//thereafter, clients interact with the context exclusively. there is
//often a family of concrete strategy classes for a client to choose from
//
//+------------------------------------------------------------------+
//| example of a client |
//+------------------------------------------------------------------+
#include <Mqh\Patterns\Strategy\Strategy.mqh>
#include <Mqh\Patterns\Strategy\ConcreteStrategyA.mqh>
#include <Mqh\Patterns\Strategy\ConcreteStrategyB.mqh>
#include <Mqh\Patterns\Strategy\ConcreteStrategyC.mqh>
#include <Mqh\Patterns\Strategy\Context.mqh>
void OnStart()
{
Context* context;
//---strategy a
context=new Context(new ConcreteStrategyA());
context.ContextInterface();
delete context;
//---strategy b
context=new Context(new ConcreteStrategyB());
context.ContextInterface();
delete context;
//---strategy c
context=new Context(new ConcreteStrategyC());
context.ContextInterface();
delete context;
}
//
// output
//
// new strategy 2097152 loaded
// requesting strategy algorithm
// executing algorithm of strategy a (2097152)
// new strategy 4194304 loaded
// requesting strategy algorithm
// executing algorithm of strategy b (4194304)
// new strategy 6291456 loaded
// requesting strategy algorithm
// executing algorithm of strategy c (6291456)
//
// consequences
//
// families of related algorithms
// an alternative to subclassing
// strategies eliminate conditional statements
// a choice of implementations
// clients must be aware of different strategies
// communication overhead between strategy and context
// increased number of objects
//
// implementation
//
// defining the strategy and context interfaces
// strategies as template parameters
// making strategy objects optional
//
// related patterns
//
// strategy objects often make good flyweights
//
//+------------------------------------------------------------------+
Comments