Perguntas sobre OOP em MQL5 - página 27
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Quais declarações em particular são infundadas?
há o suficiente.
O artigo é um artigo descartável, projetado para obter uma tempestade de fogo do pessoal do OOP e não tem nada a ver com mql porque simplesmente não há ferramentas de linguagem para FP em mql.
Portanto, não adianta discuti-lo aqui.
há o suficiente.
O artigo é um lançamento, projetado para ser queimado pelo pessoal do OOP e não tem nada a ver com mql, porque simplesmente não há ferramentas de linguagem para PF em mql.
Portanto, não adianta discuti-lo aqui.
há o suficiente.
O artigo é um lançamento, projetado para obter uma tempestade de fogo do povo OOP e não tem nada a ver com mql, porque simplesmente não há ferramentas de linguagem para FP em mql.
Portanto, não adianta discuti-lo aqui.
Os comentários são desnecessários.
Os proponentes da FP esquecem conscientemente que seu cálculo lambda é executado por uma máquina Turing, com um número finito de estados e transições entre eles, ou seja, são usados os mesmos contadores, ramificações e instruções de goto. Portanto, afirmar que a FP fornece algo mais do que a linguagem clássica como C, C#, Java pode fornecer é pelo menos incorreto.
Vasily, este artigo seria muito útil para você - para que você não se torture ao espremer o OOP por causa do OOP.
Vasily, este artigo seria muito útil para você - para que você não se torture ao espremer o OOP por causa do OOP.
Por que é tão pouco lisonjeiro? Eu gosto muito do estilo de seus artigos,
Gosto do estilo e da limpeza de seus artigos, gostaria que fossem limpos e legíveis.
Por que isso não é lisonjeiro? Eu gosto muito de seu estilo de escrita,
o código é limpo e legível - eu definitivamente o desejaria para mim mesmo - o nível é muito alto.
Infelizmente não posso apoiar esta conversa - não li nenhum artigo ou não vi nenhum código. Tratava-se de algo mais.
Infelizmente eu não posso apoiar esta conversa - não li o artigo nem vi o código. Tratava-se de algo mais.
Eu só posso dar minha opinião sobre o OOP para clareza de propósito do OOP em MQL. Eu terminei o código - foi interessante ver qual seria o resultado.
Agora eu embrulhei todas as funções para trabalhar com ordens em uma classe, e então limpei o código e removi os parâmetros nas funções, já que os campos de classe são privados - no sense.... tenho um código totalmente inutilizável para uso posterior
Sim, é conveniente que você possa adicionar pequenos métodos e ampliar a funcionalidade da classe, mas para uso futuro ... ou adicionar novos métodos sabendo que o compilador não incluirá o código não utilizado no executável ou... ... ou ... escreva tudo de novo - assim, no geral, temos um certo monstro de uma classe para trabalhar com encomendas
ou seja, a taxa de universalidade é um código inchado que você não poderá ler após alguns meses e herdará o código para não ter que descobrir o que é supérfluo em uma classe - muito ruim para o seu tempo
você pode lê-lo em princípio, nomes de métodos de acordo com as tarefas que você está prestes a executar. em geral, não estou satisfeito com o resultado - tudo é incômodo
Eu só posso dar minha opinião sobre o OOP para que haja clareza de entendimento da razoabilidade do OOP em MQL. Eu terminei o código - foi interessante ver o que eventualmente viria à tona, no início era a maneira que eu costumava escrever - depuração de funções de serviço de trabalhar com pedidos e inserção de OOP onde eu mantinha dados e pequenos métodos que eu planejava usar apenas em uma determinada tarefa, eu chamava funções de trabalhar com pedidos de classes (estilo de procedimento)
Agora eu embrulhei todas as funções para trabalhar com ordens em uma classe, e então limpei o código e removi os parâmetros nas funções, já que os campos de classe são privados - no sense.... tenho um código totalmente inutilizável para uso posterior
Sim, é conveniente que você possa adicionar pequenos métodos e ampliar a funcionalidade da classe, mas para uso futuro ... ou adicionar novos métodos sabendo que o compilador não incluirá o código não utilizado no executável ou... ... ou ... escreva tudo de novo - assim, no geral, temos um certo monstro de uma classe para trabalhar com encomendas
ou seja, a taxa de universalidade é um código inchado que você não poderá ler após alguns meses e herdará o código para não ter que descobrir o que é supérfluo em uma classe - muito ruim para o seu tempo
você pode lê-lo em princípio, nomes de métodos de acordo com as tarefas que você está prestes a executar. em geral, não estou satisfeito com o resultado - tudo é muito incômodo
Em resumo, eu fiz cocô e me perdi.
Em resumo - cague e saia.
Hmm, quem saiu? Do que você está falando? Você tem todos os comentários no meio da noite, é difícil saber o que é o quê.
...
E se você não usar aulas, você vai se cansar de escrever constantemente algo como SymbolInfoDouble(_Symbol,SYMBOL_BID). Tais danças toda vez - tanto parênteses e sublinhados, e você não sabe se deve pressionar o capslock (e depois em outro lugar sem olhar, digite toda uma corda capitalizada e digite-a novamente) ou manter o shifter pressionado. Pelo menos é aí que o OOP é útil. Se pelo menos criar classes para todas essas funções, então sim - elas são enormes. Se você o escreve por si mesmo, não é um problema. Quanto a trabalhar com pedidos, não há tantas funções utilizadas com freqüência, podemos simplesmente colocar algumas funções em uma biblioteca. Mas, em geral, ainda não existe uma abordagem ideal.