Discussão do artigo "Padrões de projeto no MQL5 (Parte I): Padrões criacionais (creational patterns)"

[MetaQuotes]

Novo artigo Padrões de projeto no MQL5 (Parte I): Padrões criacionais (creational patterns) foi publicado:

Existem métodos que podem ser usados para resolver problemas típicos. Depois de entender como usar esses métodos, você pode então escrever programas de maneira prática e aplicar o conceito DRY ("Don't Repeat Yourself" - "Não se Repita"). Neste contexto, os padrões de projeto são extremamente úteis, pois apresentam soluções para problemas bem descritos e recorrentes.

As classes de um padrão criacional usam o conceito de herança, ou seja, podem herdar propriedades e métodos de outras classes. Isso permite alterar o comportamento da classe, transformando-a em uma instância (objeto) que atende a determinados requisitos. Um objeto de um padrão criacional delega a tarefa de criar uma nova instância (instanciação) a outro objeto. Quando o programa se concentra na composição de objetos, em vez de na herança de classes, os padrões criacionais se tornam mais importantes.

Pode-se dizer que esses padrões têm dois aspetos recorrentes:

• Eles usam o conceito de encapsulamento para obter conhecimento sobre classes específicas que o sistema pode usar.
• Eles tornam o método de criação de instâncias de classes e sua união oculto.

Os padrões criacionais oferecem flexibilidade em termos do que é criado, por quem, como e quando.

Eles também permitem abstrair o processo de instanciação, pois permitem criar objetos sem repetir a mesma implementação. Isso torna o código mais flexível e simples.

Autor: Mohamed Abdelmaaboud

[Denis Kirichenko]

Achei que os tradutores tinham cometido um pequeno erro na subseção sobre fábrica abstrata, mas não - o próprio autor.

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

Portanto, podemos usar esse modelo quando:

• NÃO HÁ NADA
• Precisamos de um sistema independente.
• Precisamos de um sistema configurado com uma das muitas famílias de produtos.
• Precisamos usar uma família de produtos relacionados juntos, conforme projetado, e impor essa restrição.
• Precisamos expor apenas as interfaces da classe fornecida, não sua implementação.

Exemplos de uso de uma Abstract Factory:

No código-fonte em inglês, está:

Qual é o problema de design que ele resolve?

Portanto, podemos usar esse padrão no caso do seguinte:

• Precisamos de um sistema independente.
• Precisamos de um sistema configurado com uma das muitas famílias de produtos.
• Precisamos usar uma família de objetos de produtos relacionados juntos de acordo com seu design e impor essa restrição.
• Precisamos revelar apenas as interfaces da classe fornecida, não sua implementação.

[Rashid Umarov]

Obrigado, corrigido.

[Denis Kirichenko]

Vou ser um pouco mais mal-humorado...

Para ser preciso na terminologia, vou dar uma olhada na fonte em inglês do artigo. Então, o autor escreve "How can we use it in MQL5?" sobre cada modelo. Deve-se notar aqui que a MQL5 é uma linguagem especializada aplicada. Então, o que é isso? Nós realmente aprend emos com o material como usar modelos em MQL5? Não! Vemos apenas a implementação de um modelo em MQL5. Na minha opinião, como se trata de um modelo, deveríamos primeiro descrevê-lo em pseudocódigo, e só depois em MQL5. Idealmente, seria interessante ver exemplos práticos do uso de padrões de design em MQL5. Não sei, talvez eu esteja me adiantando e o autor planeje considerar cada modelo em uma obra separada. Mas, por enquanto, temos o que temos....

[Reza nasimi]

Senhor, obrigado pelo seu tempo e disposição para compartilhar seu conhecimento.
Como alguém que conhece MQL e também conhece e usa OOP em alguns graus, mas não tem ideia sobre padrões de design, devo dizer que não entendi o que você explicou.
Não li o artigo por completo, pois de que adianta ler parágrafo após parágrafo se não entendi nenhum deles?
A maneira de continuar aprendendo com este artigo seria me ater apenas aos seus exemplos de código e tentar entender o conceito a partir deles.
Escrevi isso apenas para compartilhar um feedback.
Mais uma vez, obrigado.

[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();
  }

Não entendo esse método.

Por que não podemos comparar se esses dois ponteiros são os mesmos e simplesmente usar:

if (factory != ap) factory = ap;

Além disso, a documentação diz

int  StringConcatenate(
   string&  string_var,   // string to form
   void argument1         // primeiro parâmetro de qualquer tipo simples
   void argument2         // segundo parâmetro de qualquer tipo simples
   ...                    // próximo parâmetro de qualquer tipo simples
   );

e factory não é de um tipo simples.