Programming Mode - Facade - MetaTrader 5 Library | MT5 EA Download - MetaTrader 5 Resources

 /**********************************************************************
Programming mode - Facade 
Provides a unified interface for a set of interfaces in a subsystem. Facades define higher-level interfaces that make subsystems easier to use.
/**/

 /************************************************************************/
class subsystemA { public : blank operationA() { print ( "subsystemA" );}}; /**/
class subsystemB { public : blank operationB() { print ( "subsystemB" );}}; /**/
class subsystem C { public : blank operation C() { print ( "subsystem C" );}}; /********************************************************************/
Class Facade { Public :
Blank operation AB() {subSystemA.OperationA(); subSystemB.OperationB();}
Blank OperationBC() {subSystemB.OperationB(); subSystemC.OperationC();} protected :
  Subsystem A Subsystem A;
  Subsystem B Subsystem B;
  Subsystem C Subsystem C;
  };

 /**********************************************************************
Applicability When using the Facade pattern *You want to provide a simple interface to a complex subsystem. Subsystems tend to become more complex as they develop. Most patterns result in more and smaller classes when applied. This makes the subsystem more reusable and easier to customize, but also becomes harder to use for customers who don't need to customize it. A skin can provide a simple default view of a subsystem which is good enough for most customers. Only customers who want more customizability will need to look beyond the surface.
      *There are many dependencies between client and implementation classes of an abstraction. Facades are introduced to decouple subsystems from clients of other subsystems, thereby promoting subsystem independence and portability.
      *You want to layer subsystems. Use facades to define the entry points for each subsystem level. If the subsystems are related, then you can simplify the dependencies between them by having them communicate with each other only through their facades.
The participant *facade* knows which subsystem class is responsible for the request.
      * Delegate client requests to appropriate subsystem objects.
  *Subsystem class *Realizes subsystem functions.
      *Handle the work of Facade object allocation.
      *Know nothing about the facade; that is, they retain no references.
Cooperation *The client communicates with the subsystem by sending requests to the Facade, which
    Forward them to the appropriate subsystem object. While the subsystem object performs the actual work, the facade may have to do the work itself by converting its interface into the subsystem interface.
  *Clients using a facade do not have to access its subsystem objects directly.
Consequences The Facade pattern has the following advantages:
      1. It shields the client from subsystem components, thereby reducing the number of subsystem components objects handled by the client and making the subsystem easier to use.
      2. It promotes weak coupling between the subsystem and its clients. 
        Components in subsystems are often strongly coupled. Weak coupling allows you to have different components of a subsystem without affecting its clients. Facades Help layer Dependencies between systems and objects. They can eliminate complex or circular dependencies. When the customer implements each subsystem independently.
        Reducing compilation dependencies is critical for large software systems. You want to save time by minimizing recompilation when subsystem classes change.        Reducing compilation dependencies on facades can limit recompilations that require small changes to important subsystems. Facades can also simplify porting the system to other platforms, since building one subsystem is less likely to require building all the other subsystems.
      3. It does not prevent applications from using subsystem classes when needed.
        So you can choose between ease of use and versatility.
Related Patterns *Abstract Factory can be used in conjunction with Facade to provide an interface for creating subsystem objects in a subsystem-independent manner. You can also use an abstract factory as an alternative to a Facade to hide platform-specific classes.
  *Mediator is similar to Facade in that it abstracts the functionality of existing classes.
    However, the purpose of a Mediator is to abstract arbitrary communication between co-workers, often focusing functionality that does not belong to any one of those objects. A mediator's colleagues understand and communicate with the mediator, rather than communicating directly with each other. In contrast, a facade merely abstracts the interfaces of subsystem objects to make them easier to use; it does not define new functionality, and the subsystem classes are unaware of it.
    Usually only one Facade object is needed. Therefore Facade objects are usually Singletons
/**/

/**********************************************************************
Example of using the Facade pattern. client.
/************************************************************************/
blank start ()
  {
  facade facade;
  Facade.OperationAB();
    { string s; for ( integer i = 0 ; i < 11 ; i++) {s+= “-” ;} print (s);}
  Facade.OperationBC();
  } /************************************************************************
Output:
  Subsystem A
  Subsystem B
  ----------
  Subsystem B
  Subsystem C
/**/

Attachment download

📎 facade.mq5 (0.54 KB)

📎 facade.mqh (10.21 KB)

Source: MQL5 #29802