A OOP será procurada na MQL5? - página 3
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
Pelo menos o aprendizado da MQL4 não será uma perda de tempo. Se você tiver usado apenas indicadores padrão, a conversão, como eu entendo, não será muito difícil.
Eu acho que o programador semi-profissional médio não precisará de OOP em MQL5.
Se eu tiver uma boa impressão de que a velocidade será maior em todos os aspectos, prefiro não olhar para tais indicadores que podem resolver grandes problemas. Repito - não sou um profissional.
Embora, talvez agora os entusiastas usem a MQL5 para simular o surgimento da vida a partir do caldo primário? ;)
P/S Esqueci. Funções de tratamento de eventos. Gud.
... biblioteca retorna uma interface (uma classe com funções virtuais). No caso de uso "descoordenado" comigo, ele retorna uma interface de stub (com falhas de computação não muito óbvias).
Você pode fazê-lo sem jurar? As mulheres às vezes vêm ao fórum aqui.
Haverá um benefício de proteção - a biblioteca EX5 retorna uma interface (uma classe com funções virtuais). Em caso de uso "descoordenado" comigo, devolve o stub de interface (com erros de cálculo não muito óbvios).
Se valer a pena, eles o quebrarão, e a interface com humanóides limpos não ajudará :)
Portanto, a proteção é a mesma de qualquer outro lugar - sem acesso físico ao código, mais um atraso necessário para TS específica com análise comercial (o investidor de capital pode ser dado em tempo real).
Bem, o OOP em EAs é uma coisa muito valiosa, a começar pelos eventos, possibilidade de apoio competente e ajuste fino, etc. É claro que não entendo porque C# não foi uma boa idéia, porque a ausência de uma estrutura MQL5 com declarações claras de espaço de nomes, bem como uma linguagem não padronizada + imatura, exigirá mais esforços do que os inicialmente razoáveis de todos :(
Eles não têm mais OOP no seu núcleo (embora o OOP absoluto seja praticamente inutilizável). Deveríamos ter criado classes abstratas desde o início e usado herança e polimorfismo para alcançar objetos reais. Por exemplo, para criar uma classe base abstrata para indicadores personalizados com métodos e propriedades abstratas. É melhor construir uma árvore hierárquica de classes: uma árvore para objetos gráficos, para trabalhar com a conta, para horários e acesso à série cronológica, etc. E para procedimentos e funções pré-definidos, apenas as rotinas elementares que requerem velocidade devem ser deixadas. Então você poderia expandir as capacidades da plataforma a partir de qualquer nível de abstração, o que reduziria o tamanho do código, melhoraria sua legibilidade e facilidade de compreensão para outros programadores. E no MT5 já foram implementadas coisas bastante complexas em nível de procedimentos (de fato, toda a plataforma está pronta para uso) e ainda não vi a possibilidade de acesso por meio de indicadores pelo menos aos descritores das estruturas internas criadas, o que é muito limitador (a julgar pela ajuda). Em geral, a necessidade de OOP é questionável, com tal implementação poderíamos nos limitar a estruturas e colocação dinâmica. O OOP deve ser apoiado a partir de baixo por uma hierarquia de classes bem desenvolvida.
Sim. É isso que estou dizendo. A forma como é feito, IMHO, dificilmente será muito útil. É para isso que isto serve. Mas, ainda assim, talvez haja outras opiniões?
Apitos e campainhas, com certeza. No entanto, se houver algum suporte para objetos externos, isso é ótimo.
Sem espaços de nomes, não é realmente viável.
Sem os namespaces, não é realmente viável fornecer o suporte adequado.
É possível prescindir desta última fantasia da Microsoft. Mas você não pode passar sem estas últimas coisas chiques como " bibliotecas de interface ", pelo menos enquanto falamos sobre winnda. Na verdade, é uma pena que os desenvolvedores da MT pareçam ter jurado uma fidelidade eterna à melkomsoft até o túmulo e não prestarem nenhuma atenção ao resto. Meu instinto me diz que fazer com que mesmo o MT5 funcione completamente sem pecado sob Linux via Wine será uma verdadeira dor de cabeça.