Programming Mode - Builder (Classic) - MetaTrader 5 Scripts - MT4/MT5 Resources

 /****************************************************************************
                                                          MQL5 Script Copyright 2019, DMIPEC
                                                      792112@gmail.com

The classic builder programming pattern. This pattern was published in "Design Patterns: Elements"
  Reusable Object-Oriented Software, 1st Edition, by Erich Gamma
  (Author), Richard Helm (Author), Ralph Johnson (Author), John Vlissides (Author), Grady Booch (Foreword). These authors are collectively known as the Gang of Four (GoF).

The structure shown in the figure represents the construction of a complex object separately from the structure of the object itself, so that the same construction process can create different representations.

Applicability* Algorithms for creating complex objects should be independent of the parts that make up the object and how they are assembled.
 * The construction process must allow for different representations of constructed objects.

Participants Builder * Specifies the interface used to create the various parts of the Product object.
  Concrete Builder * Constructs and assembles the individual parts of the product by implementing a builder interface.
    * Define and track the representations it creates.
    * Provide an interface for retrieving products.
  Director * Use the Builder interface to construct an object;
  Product Display * represents the complex object being built. Concrete Builder builds the internal representation of the product and defines its assembly process.
    * Includes classes that define the component parts, including interfaces for assembling the parts into the final result.

Cooperation (see picture)
 * The client creates the Director object and configures it with the required generator objects.
  The supervisor notifies the builder whenever a part of the product is needed to be built.
 *Builder handles director's requests and adds parts to products.
 * The client retrieves the product from the builder.

Consequences It allows you to change the internal representation of your product.
      The Builder object provides the director with an abstract interface for constructing products. This interface lets the builder hide the presentation and internal structure of the product. It also hides how the product is assembled. Because the product is built through an abstract interface, you must change the internal representation of the product by defining a new builder.
  It isolates construction and presentation code.
      The Builder pattern improves modularity through encapsulation. A complex object is constructed and represented. The client does not need to know anything about the classes that define the product's internal structure; this class does not appear in the Builder interface. Each builder contains all the code to create and assemble a specific type of product. Code is written once;
      Different executives can then reuse it to build product variations from the same set of parts.
  It gives you more control over the construction process.
      Unlike the creative model of building a product once,
      Builder mode builds products step-by-step under director's control. Only when the product is completed the director takes it back from the builder. As a result, the builder interface reflects more about the process of building a product than other authoring modes. This gives you greater control over the entire construction process and internally the structure of the resulting product.

Implementations* typically have an abstract Builder class that defines the operations that a director may require of each component it creates.
  By default, these operations do nothing. ConcreteBuilder class Overrides operations for components it is interested in creating.
 *The following are additional implementation issues to consider:
      Assembly and construction interfaces.
        Builders build their products in a step-by-step manner.
        Therefore the interface of the Builder class must be generic enough to allow the construction of various types of concrete builders. A key design issue involves the model construction and assembly process. A model where the results of the construction request are simply attached to the product is usually sufficient. But sometimes you may need to access parts of a previously built product. In that case, the builder returns the child node to the director,
        They are then passed back to the builder to build the parent node.
      Why is there no abstract class for product?
        In general, the products produced from concrete builders vary so widely in their representation that there is little advantage in providing common benefits to different parent classes. Because the client will typically configure the supervisor with the appropriate concrete builder, the client knows where the specific subclasses of Builder are used and can handle their products accordingly.
      The default method in Builder is empty.
        In C++, build methods are intentionally not declared as pure virtual member functions. They are defined as empty methods instead, letting clients override only the operations they are interested in.

Code output Construction in progress...
      Part A is built, Part B is built, Part C is built, and the finished product "real product" is delivered.
  This "real product" is made of:
      Part A Part B Part C*/

Attachment download

📎 c_builder.mq5 (24.69 KB)

Source: MQL5 #26799