Que código OOP pode fazer que o código de procedimento não pode? - 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
Programar GUIs foi o que eu mais fiz durante todo o meu tempo como programador. Não é possível codificar uma GUI completa que precisa se comunicar em várias direções até então. Você precisaria de tantas declarações de que o código se tornaria ilegível e, no final, muito lento, o que resultaria em não alcançar o objetivo. Fato.
Eu não vou construir uma GUI em linguagem de procedimento para provar que você está errado. Mas eu poderia, sem qualquer dúvida.
A propósito, também é fácil codificar códigos ilegíveis e muito mais lentos no OOP, e como você sabe, a Metaquotes Standard Library é uma boa prova disso.
...
Devido à circunstância de uma CPU não saber nada sobre OOP, você pode - é claro - codificar tudo sem usar apenas apontadores e arrays complexos. Mas isso é um absurdo. Eu também poderia contratar 10000 pessoas que desenham meu conteúdo de tela no filme em tempo real e o teletransportam sequencialmente por um projetor de luz na parede. Isto também está atingindo o objetivo?
Você concorda que o sistema operacional Windows está oferecendo uma boa GUI? Tanto quanto sei, está escrito em linguagem C. Procedural e não OOP.
Você está errado Dirk se você acha que um programa complexo só poderia ser construído com o OOP. Você deveria antes explicar por que é melhor codificá-lo com OOP.
Vamos lá ;) Nem por isso ;) Se algo nativo poderia fazer o trabalho de alguma forma estranho, então suas indicações, mas há restrições na MQL. Se assim não fosse ... o código se tornaria absurdo.
Duvido muito que o OOP seja uma forma mais curta de codificação.
Você concorda que o sistema operacional Windows está oferecendo uma boa GUI? Tanto quanto sei, está escrito em linguagem C. Procedural e não OOP.
Você está errado Dirk se você acha que um programa complexo só poderia ser construído com o OOP. Você deveria antes explicar por que é melhor codificá-lo com OOP.
Eu codifiquei GUIs em Assembler, inteiramente. Mas em Assembler eu posso trabalhar com ponteiros, em C eu posso trabalhar com ponteiros e claro que o básico do Windows não é OOP, mas falamos de MQL que não suporta ponteiros vazios da maneira nativa e por causa disso, você não será capaz de codificar GUIs complexas com apenas se for assim, pelo menos não com um resultado que possa ser usado sem grande falta de performance.
E esta resposta já inclui a pergunta, por que é melhor com OOP - onde "melhor" ainda é o adjectivo errado. O método OOP implementa o uso de tais indicadores, mas sem forçar você a lidar com eles. Internamente, o OOP é realizado com matrizes multi-dimensionais para a função e ponteiros variáveis. Tentar codificar coisas assim é o mesmo que reinventar uma roda que nunca vai rolar tão suave como aquela que você já tem na sua frente.
Eu codifiquei as GUIs em Assembler, inteiramente. Mas em Assembler eu posso trabalhar com ponteiros, em C posso trabalhar com ponteiros e claro que o básico do Windows não é OOP, mas falamos de MQL que não suporta ponteiros vazios da maneira nativa e por causa disso, você não será capaz de codificar GUIs complexas com apenas se for assim, pelo menos não com um resultado que possa ser usado sem grande falta de performance.
E esta resposta já inclui a pergunta, por que é melhor com OOP - onde "melhor" ainda é o adjectivo errado. O método OOP implementa o uso de tais indicadores, mas sem forçar você a lidar com eles. Internamente, o OOP é realizado com matrizes multi-dimensionais para a função e ponteiros variáveis. Tentar codificar coisas assim é o mesmo que reinventar uma roda que nunca vai rolar tão suave como aquela que você já tem na sua frente.
É apenas a minha preferência pessoal devido à minha pequena(!) experiência!
1) Eu não gosto, por exemplo, de Java, pois eu estava procurando 99% do tempo por uma função sem saber qual poderia ser seu nome, se ela existe ou não e se eu mesmo tenho que codificá-la de qualquer forma ...
2) Eu não gosto de C++ porque tenho que escrever mais do que eu não gostaria de escrever um script como a linguagem mq4 ou mesmo Perl.
3) Eu não gosto de C++ porque compreender o código de outra pessoa me permite saltar de arquivo em arquivo onde eu só encontro funções com 2,3 linhas, o que torna realmente difícil descobrir o que e como o s.th. é calculado. Claro que existem explicações como "calcular a parada", mas o procedimento de cálculo também é dividido em várias funções em diferentes arquivos.
4) Eu estou absolutamente bem com enumeração e arrays de enum-variáveis. Eu não preciso codificar objetos reais imaginados. As GUIs podem ser um problema diferente, pois consistem em muitas outras coisas que poderiam ser codificadas como objetos para uma maneira fácil de reutilizá-las. Mas quantos objetos diferentes são necessários para uma EA? Um para as posições? Se houvesse muitos 'objetos' (GUI) diferentes, isso poderia ajudar - mas não os vejo aqui.
5) Finalmente, o MQ5 ainda não consegue executar seu backktest em carrapatos de clientes:( <Edited by moderator as off-topic : isto não tem nada a ver com mql5, mas com MT5>
eu realmente respeito alguém que codifica, você deve ter um bom conhecimento de como o próprio hardware funciona, simplesmente incrível, ninguém usa hoje
Eu não o codifico mais, mas no passado realmente principalmente. Nos chips Intel 80x86, era a única chance de alcançar uma vantagem real em vista do desempenho visual. E claro, é um conhecimento básico que eu não quero mais perder, mesmo que eu não precise mais dele em detalhes, mas você sempre sabe o que acontece com seu código no final e sabe como usá-lo como uma vantagem em vista da velocidade de execução.
Sim, "bons" velhos tempos ;) ... Mas insano também, não havia nem mesmo variáveis, nem funções reais, nem se então, apenas registros, pilhas, interrupções e endereços de memória. Merda maluca :)
OOP é uma ferramenta para código dividido em pequenas peças reutilizáveis. Mas a melhor parte são os modelos. Esta característica permite a simplificação do código. O melhor exemplo é a classe array. Em Java, você criou uma classe para tipo. Em C++ e Mql5 você pode tê-la em uma classe reduzindo o código redundante e contornando alguns problemas quando você mistura primitivas e objetos
PS: Sobre a ASM, é a velha escola. Eu o usava quando antes de proteger pela primeira vez os compiladores de modo e era engraçado ultrapassar as limitações da passagem. Segmentos de 64K com seletores era o pesadelo dos codificadores naquela época. Toda vez que você lutava no lugar errado, você tinha sido reiniciado no computador :)