Perguntas sobre OOP em MQL5 - página 23

Novo comentário
 
Vladimir Simakov:
Mostrarei a vocês mais tarde esta noite. Agora do meu telefone.

OK

Não é um problema remover a herança da interface, você pode herdar de uma classe base, mas na minha opinião haverá confusão no código - será mais difícil entender qual método será chamado, e com esta estrutura de código - "Padrão OOP - Padrões de comportamento - Estratégia".

Estou sempre e com garantia de ter um construtor em cada estratégia, parece que esses construtores ainda não são necessários... mas vou deixar essa possibilidade, não é supérflua

ZS: a própria classe base para todas as estratégias também é bastante compacta, a respeito disso:

class CStrategy: public IStrategy
{
protected:
   SSettingsForOrder  m_setting;
   COrder *m_order;
   void RunStrategy();
   double CalcLot();
   double GetPrice(); 
};

Até agora eu gosto que a estrutura do código seja legível e lógica, e o mais importante "em todos esses gestos" é fazer algum tipo de protótipo, o que permitirá adicionar rapidamente estratégias em si e testá-las.

Eu já tinha escrito tudo em princípio, mas não gosto do código - escrevi funções de serviço (para abrir um pedido, calcular lotes, etc.) em estilo processual e depois escrevi pequenas classes com lógica e chamadas dessas funções de serviço e decidi torná-lo o melhor possível)))

 
Igor Makanu:

OK

Não é um problema remover a herança da interface, você pode herdar de uma classe base, mas na minha opinião haverá confusão no código - será mais difícil entender qual método será chamado, e com esta estrutura de código - "Padrão OOP - Padrões de comportamento - Estratégia".

Estou sempre e com garantia de ter um construtor em cada estratégia, parece que esses construtores ainda não são necessários... mas vou deixar essa possibilidade, não é supérflua

ZS: a própria classe base para todas as estratégias também é bastante compacta, a respeito disso:

Até agora eu gosto que a estrutura do código seja legível e lógica, e o mais importante "em tudo isso" é fazer algum tipo de protótipo, o que permitirá rapidamente adicionar estratégias e testá-las.

Eu já tinha escrito tudo em princípio, mas não gosto do código - escrevi funções de serviço (para abrir um pedido, calcular lotes, etc.) em estilo processual e depois escrevi pequenas classes com lógica e chamadas dessas funções de serviço e decidi torná-lo o melhor possível)))

//+------------------------------------------------------------------+
class CStrategy
{
protected:
   int x;
public:
   CStrategy(int _x):x(_x){}
   virtual void Algorithm()=0;};
//+------------------------------------------------------------------+
class CStrategy_01:public CStrategy
{
public:
   CStrategy_01():CStrategy(1) {Print(__FUNCTION__);}
   void Algorithm()                 {Print(__FUNCTION__,", x = ",x);       } };
//+------------------------------------------------------------------+
class CStrategy_02:public CStrategy
{
public:
   CStrategy_02():CStrategy(2) {Print(__FUNCTION__);}
   void Algorithm()                 {Print(__FUNCTION__,", x = ",x);       } };
//+------------------------------------------------------------------+
class Context
{
private:
   CStrategy         *s;
public:
   Context(CStrategy* _strategy):s(_strategy) { Print(__FUNCTION__);}
   ~Context()                       { delete s;                            }
   void              GetStrategy()  { s.Algorithm();                       } };
//+------------------------------------------------------------------+
Context c1(new CStrategy_01);
Context c2(new CStrategy_02);
//+------------------------------------------------------------------+
void OnStart()
{  c1.GetStrategy();
   c2.GetStrategy(); }

Isso me soa melhor.

 
Vladimir Simakov:

A mim me parece melhor assim.

essencialmente a mesma coisa, mas não pelo livro! ))))

ZS: Eu parafusei na interface de qualquer maneira, que seja, puramente para mostrar!

 
Igor Makanu:

essencialmente a mesma coisa, mas não pelo livro! ))))

ZS: De qualquer forma, deixem estar, eu parafusei na interface, puramente para mostrar!

Só no estilo dos profissionais))))
 
Vladimir Simakov:
Só no estilo de pluses)))

Poucas pessoas usam C#, ou melhor, todos os programadores de aplicações mudaram para C#, e apenas grandes desenvolvedores de software usam C#

todos os exemplos em C# são via interfaces, por isso é claro que são inúteis .... Eu não quero entrar em brigas, mas você pode escrever tudo sem interfaces, o conceito, o estilo... mas o conceito, estilo e outras neblinas cerebrais me dizem que era assim que a Microsoft costumava escrever exemplos em C# - basta sentar e escrever desta forma também!

)))

 
Igor Makanu:

Poucas pessoas usam C#, ou melhor, todos os programadores de aplicações mudaram para C#, e apenas grandes desenvolvedores de software usam C#

todos os exemplos em C# são via interfaces, por isso é claro que são inúteis .... Eu não quero entrar em brigas, mas você pode escrever tudo sem interfaces, o conceito, o estilo... mas o conceito, estilo e outras neblinas cerebrais me dizem que era assim que a Microsoft costumava escrever exemplos em C# - basta sentar e escrevê-los dessa maneira também!

)))

Movido porque é inconveniente escrever sobre as vantagens sob .NET, e Sharp foi originalmente projetado como uma linguagem para dotnet. Essa é minha opinião pessoal, a princípio eu escrevi pluses em .NET, que me pareceu desajeitada.

Embora... eles tenham acrescentado muito aos novos profissionais, talvez seja mais divertido.

 
Alexey Volchanskiy:

Trocamos porque o uso de pluses é inconveniente para escrever em .NET, e Sharp foi originalmente desenvolvido como uma linguagem para dotnet. Esta é a minha opinião subjetiva, uma vez que escrevi em pluses sob .NET, fiquei com uma impressão de desajeito.

Embora... eles tenham acrescentado muito aos novos profissionais, talvez seja mais divertido.

Agora estou apenas escrevendo o formulário de janelas para uma tarefa, toquei c++/cli e decidi não usá-lo e imprimi c#.
 
Vladimir Simakov:
Agora estou escrevendo o formulário de janelas para uma tarefa, toquei c++/cli e decidi esquecê-lo e imprimi c#.

Sim, é mais fácil de afiar por uma ordem de grandeza. E a velocidade é quase a mesma, ou seja, sem cliente os profissionais ganham por um fator e meio.

 
Vladimir Simakov:
Agora estou escrevendo um formulário de janela para uma tarefa, toquei c++/cli e decidi não usá-lo e imprimi c#.

Tentei tocar no cli no início do ano ... Fiquei satisfeito por 2 dias, a lógica desumana de quem fez este cliente - a sintaxe é complicada, tudo não é conveniente, há muito pouca informação com exemplos, imho ou puro C++ ou C# - google all the wants, a sintaxe é clara - como resultado, você pega e escreve

 
Igor Makanu:

Tentei tocar no cli no início do ano ... A sintaxe é complicada, tudo não é conveniente, há muito pouca informação com exemplos, imho - ou puro C++ ou C# - todos os desejos são pesquisados no Google, a sintaxe é clara - finalmente você obtém e escreve

Sharp nasceu por volta do ano 2000 e estava em sua infância, mas as vantagens eram grandes, de modo que eles faziam a ponte entre C++ e Dotnet para a popularização. A propósito, Sharp foi criado por Delphi e desenvolvedores de C++Builder, eu me perguntava, naquela época, quantos conceitos comuns existem. Tomar as mesmas propriedades, eventos.

1...161718192021222324252627282930...96
Novo comentário
Razão: