Discusión sobre el artículo "Patrones de diseño en MQL5 (Parte I): Patrones de creación (Creational Patterns)"

[MetaQuotes]

Artículo publicado Patrones de diseño en MQL5 (Parte I): Patrones de creación (Creational Patterns):

Existen métodos que pueden usarse para resolver problemas típicos. Una vez entendemos cómo utilizar estas técnicas una vez, podemos escribir programas de forma eficaz y aplicar el concepto DRY (No te repitas, en inglés, don't repeat yourself). En este contexto, resultan muy útiles los patrones de diseño que pueden aportar soluciones a problemas bien descritos y recurrentes.

Las clases del patrón de creación utilizan el concepto de herencia, lo que significa que pueden heredar propiedades y métodos de otras clases. Esto permitirá modificar el comportamiento de una clase, convirtiéndola en un ejemplar (objeto) que cumpla determinados requisitos. El objeto de patrón de creación delegará la tarea de creación de un nuevo ejemplar (ejemplarización) en otro objeto. Cuando un programa se centra en la composición de objetos más que en la herencia de clases, la creación de patrones adquiere mayor importancia.

Podemos decir que estos patrones tienen dos temas recurrentes:

• Utilizan el concepto de encapsulación para conocer las clases específicas que puede usar el sistema.
• Hacen que el método de creación de ejemplares de clase y su combinación quede oculto.

Los patrones de creación ofrecen flexibilidad en cuanto a qué se crea, quién lo crea, cómo y cuándo.

También permiten abstraer el proceso de ejemplarización porque permiten crear objetos sin repetir la misma implementación. Todo ello hace que el código resulte más flexible y sencillo.

Autor: Mohamed Abdelmaaboud

[Denis Kirichenko]

Pensé que los traductores habían cometido un pequeño error en la subsección sobre fábrica abstracta, pero no - el propio autor.

Какую проблему проектирования он решает?

Por lo tanto, podemos utilizar esta plantilla cuando

• NO HAY NADA
• Necesitamos un sistema independiente.
• Necesitamos un sistema configurado con una de muchas familias de productos.
• Necesidad de utilizar una familia de productos relacionados juntos como diseñado y hacer cumplir esta restricción.
• Necesitamos exponer sólo las interfaces de la clase proporcionada, no su implementación.

Ejemplos de uso de una Abstract Factory:

En el código fuente inglés es:

¿Qué problema de diseño resuelve?

Así, podemos utilizar este patrón en el caso de lo siguiente:

• Necesitamos un sistema independiente.
• Necesitamos un sistema configurado con una de muchas familias de productos.
• Necesitamos utilizar una familia de objetos de producto relacionados entre sí según su diseño y hacer cumplir esta restricción.
• Necesitamos revelar sólo interfaces de la clase proporcionada, no su implementación.

[Rashid Umarov]

Gracias, corregido.

[Denis Kirichenko]

Voy a ser un poco más gruñón...

Para ser preciso en la terminología, me fijaré en la fuente inglesa del artículo. Así, el autor escribe "How can we use it in MQL5?" sobre cada plantilla. Cabe señalar aquí que MQL5 es un lenguaje especializado aplicado. Entonces, ¿qué es?¿Realmente aprendemos del material como usar las plantillas en MQL5? No, sólo vemos la implementación de una plantilla en MQL5. Imho, ya que es una plantilla, primero debemos describirlo en pseudocódigo, y sólo entonces en MQL5. Idealmente, sería interesante ver ejemplos prácticos de la utilización de patrones de diseño en MQL5. No sé, a lo mejor me estoy adelantando y el autor tiene pensado considerar cada plantilla en un opus aparte. Pero por ahora tenemos lo que tenemos....

[Reza nasimi]

Señor, Gracias por su tiempo y voluntad de compartir sus conocimientos.
Como alguien que sabe MQL y también sabe y utiliza OOP en algunos grados, pero no tiene idea acerca de los patrones de diseño, tengo que decir que no entendí lo que explicaste.
No lo leí completamente, porque cuál es el punto de leer párrafo tras párrafo si yo no entendía ninguno de ellos.
La forma en que voy a seguir aprendiendo de este artículo sería pegarse a sus ejemplos de código sólo, y tratar de entender el concepto de eso.
Escribí este puramente para compartir una retroalimentación.
Gracias de nuevo.

[Spoxus Spoxus]

void FactoryClient::Switch(AbstractFactory *af)
  {
   string sFactory;
   StringConcatenate(sFactory,sFactory,factory);
   int iFactory=(int)StringToInteger(sFactory);
   if(iFactory>0)
     {
      Print("Factory client switches the old factory ",factory," to the new one ",af);
     }
   else
     {
      Print("Factory client accepts the new factory ",af);
     }
   Delete();
   factory=af;
   Print("Factory client saved the new factory");
   Print("Factory client requests its new factory to create the Product A");
   apa=factory.CreateProductA();
   Print("Factory client requests its new factory to create the Product B");
   apb=factory.CreateProductB();
  }

No entiendo este método.

¿Por qué no podemos comparar si estos 2 punteros son iguales y simplemente usar:

if (factory != ap) factory = ap;

Además, la documentación dice

int  StringConcatenate(
   string&  string_var,   // cadena a formar
   void argument1         // primer parámetro de cualquier tipo simple
   void argument2         // segundo parámetro de cualquier tipo simple
   ...                    // siguiente parámetro de cualquier tipo simple
   );

y factory no es de tipo simple.