A OOP será procurada na MQL5? - página 2
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
Em que você está interessado, no processo ou no resultado final?)
Estou interessado em ambos, mas o resultado final é de alguma forma mais. ("... OOP lhe dá muitas maneiras de diminuir a velocidade de seus programas...")
Não vejo onde o OOP me permitiria escrever mais rápido do que com uma abordagem procedural, e isso compensaria todas as desvantagens do OOP. É claro quem precisa dele - o desenvolvedor que escreve para os outros.
Deixe-me fazer uma analogia: o primeiro pegou uma faca e esculpiu uma figura de filigrana, enquanto o segundo cortou metade de seu dedo com a mesma faca. Qual é o objetivo disso? Qualquer ferramenta pode ser usada para criar tanto um "querido" quanto um vagabundo total. Tudo depende do programador, quer ele seja um artesão ou tenha uma centelha de talento. Isto é uma digressão, mas em essência - se você preferir o FOP, então use-o mais.
Ao criar o sujeito, eu queria ver argumentos a favor do OOP em projetos para fins de MT. Talvez devido à minha ignorância - não estou sendo flertador - não os vi. Eu também não os vejo agora.
Deixe-me resumir seus cargos (obrigado a todos, a propósito):
1. Conveniência e rapidez de implementação do projeto.
2. Manutenção, atualizações.
3. 5 é mais rápido porque quem se importa como programar.
3. A movimentação como um motivo para uma OOP mais lenta.
------------
(encolher de ombros) Entenda que eu não sou contra o OOP, eu só queria descobrir por mim mesmo o que ele pode me dar em tarefas para MT - na criação de índices, roteiros, Expert Advisors.
OK. Há uma ajuda no dia 5. Quem pode dar um exemplo de um simples indireto da norma MT4 escrito usando OOP em 5? Você poderá ver lá. Você também pode estimar os atrasos por olho a partir do texto, a legibilidade do programa, etc.
1. A conveniência e a rapidez do projeto.
2. Manutenção, atualizações.
1. O OOP é muito conveniente para aqueles que compreendem os princípios básicos. Você pode senti-lo mesmo nas aplicações mais simples. Qualquer aplicação é mais conveniente de se fazer com o OOP.
2. O tamanho de um projeto não é um impedimento, desde que não seja difícil entendê-lo. E se um programa é orientado a objetos, não é muito difícil entendê-lo. Um exemplo é o terminal SaxoBank. É escrito em C#, que é uma linguagem orientada a objetos. Cada dll contém cerca de 20 000 linhas de código. Se não fosse pela OOP, seria quase impossível entender tal quantidade de informação, ainda mais para modernizá-la.
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 extensa .
São necessários 1-3 anos de programação para perceber que os programas NÃO estão ESCRITOS, mas LEITORES.
Leva mais 1-2 anos para perceber que os programas são escritos não para um computador, mas para um humano (em particular, para si mesmo).
Então leva 1-2 anos para perceber que OOP e C++ contradizem a forma humanóide de pensar e o método de construção de línguas humanas.
Leva mais 1-2 anos para estudar o código de outras pessoas e perceber que os melhores e mais confiáveis programas são escritos na clássica Ce.
Bem depois disso, basta ler a entrevista de Dijkstra sobre C++ e OOP dando-lhe dores de estômago.
E depois disso (4-9 anos no total) as perguntas "sobre o OOP" não surgem de forma alguma, e tais discussões causam apenas um sorriso indulgente.
E depois disso (4-9 anos no total) as perguntas sobre "OOP" não surgem de forma alguma, e tais discussões evocam apenas um sorriso condescendente.
>> Eu me solidarizo.