observer (pull model) - behavioral design pattern - libreria per MetaTrader 5

//+------------------------------------------------------------------+
//|                                                201111_104313.mqh |
//|                                    2019-2020, dimitri pecheritsa |
//|                                                 792112@gmail.com |
//+------------------------------------------------------------------+
//
//   observer (pull model) - 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 one-to-many dependency between objects so that when one object
//changes state, all its dependents are notified and updated automatically
//
//   applicability
//
//   when an abstraction has two aspects, one dependent on the other.
//encapsulating these aspects in separate objects lets you vary and reuse
//them independently
//   when a change to one object requires changing others, and you don't
//know how many objects need to be changed
//   when an object should be able to notify other objects without making
//assumptions about who these objects are. in other words, you don't want
//these objects tightly coupled
//
//   structure
//
//                            observers
//   |       Subject        |---------------------->*|Observer|
//   |----------------------|                        |--------|
//   |Attach(Observer)      |                        |Update()|
//   |Detach(Observer)      |                            ^
//   |Notify()              |                            |
//   | forall o in observers|                            |
//   |  o.Update()          |                            |
//              ^                                        |
//              |                              |  ConcreteObserver  |
//              |                      subject |--------------------|
//   |    ConcreteSubject    |<----------------|Update()            |
//   |-----------------------|                 | observerState=     |
//   |GetState()             |                 |  subject.GetState()|
//   | return subject.State()|                 |--------------------|
//   |SetState()             |                 |observer_state      |
//   |-----------------------|
//   |subject_state          |
//
//   participants
//
//   subject
//      knows its observers. any number of observer objects may observe
//a subject
//      provides an interface for attaching and detaching observer objects
//   observer
//      defines an updating interface for objects that should be notified
//of changes in a subject
//   concrete subject
//      stores state of interest to concrete observer objects
//      sends a notification to its observers when its state changes
//   concrete observer
//      maintains a reference to a concrete subject object
//      stores state that should stay consistent with the subject's
//      implements the observer updating interface to keep its state consistent
//with the subject's
//
//   collaborations
//
//   concrete subject notifies its observers whenever a change occurs
//that could make its observers' state inconsistent with its own.
//   after being informed of a change in the concrete subject, a concrete
//observer object may query the subject for information. concrete observer
//uses this information to reconcile its state with that of the subject.
//
//   aConcrete              aConcrete          another
//    Subject                Observer      ConcreteObserver
//       |                      |                 |
//       |           SetState() |                 |
//      | |<-------------------| |                |
//      | |Notify()            | |                |
//      | |-----------+         |                 |
//      | |           |         |                 |
//      | |<----------+         |                 |
//      | |Update()             |                 |
//      | |------------------->| |                |
//      | |          GetState()| |                |
//      | |<-------------------| |                |
//      | |Update()             |                 |
//      | |---------------------|--------------->| |
//      | |                     |      GetState()| |
//      | |<--------------------|----------------| |
//       |                      |                 |
//
//   note how the observer object that initiates the change request postpones
//its update until it gets a notification from the subject. notify is
//not always called by the subject. it can be called by an observer or
//by another kind of object entirely.

//+------------------------------------------------------------------+
//| client                                                           |
//+------------------------------------------------------------------+
#include <Mqh\Patterns\ObserverPull.mqh>
#include <Mqh\Patterns\SubjectPull.mqh>
#include <Mqh\Patterns\ConcreteSubjectPull.mqh>
#include <Mqh\Patterns\ConcreteObserverPull.mqh>

void OnStart(void)
  {
   ConcreteSubject subject;
   subject.Attach(new ConcreteObserver(&subject));
   subject.Attach(new ConcreteObserver(&subject));
   subject.State("new pull state");
   subject.Notify();
  }
//
//   output
//
//   subject state set to: new pull state
//   observer 2097152 pulling state from subject...
//   observer 2097152 state set to: new pull state
//   observer 3145728 pulling state from subject...
//   observer 3145728 state set to: new pull state
//
//   consequences
//
//   the observer pattern lets you vary subjects and observers independently.
//you can reuse subjects without reusing their observers, and vice versa.
//it lets you add observers without modifying the subject or other observers.
//   further benefits and liabilities of the observer pattern include
//the following:
//      abstract coupling between subject and observer
//      support for broadcast communication
//      unexpected updates
//
//   implementation
//
//   mapping subjects to their observers
//   observing more than one subject
//   who triggers the update?
//   dangling references to deleted subjects
//   making sure subject state is self-consistent before notification
//   avoiding observer-specific update protocols: the push and pull models
//   specifying modifications of interest explicitly
//   encapsulating complex update semantics
//   combining the subject and observer classes
//
//   related patterns
//
//   mediator
//   singleton
//+------------------------------------------------------------------+