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
Na minha opinião, estás muito enganado!
Assim que tiver grandes projectos (pelo menos vários milhares de linhas de código), verá que a programação com classes (OOP) torna muito fácil controlar o processo de desenvolvimento e, mais importante ainda, o processo de depuração.
Além disso, o OOP torna os projectos mais próximos da vida real, de facto na vida real lidamos apenas com instâncias de objectos (uma casa, uma árvore, um homem, um carro, uma ordem, etc.), ou seja, com um conjunto de propriedades e métodos :)
Tente fazer algo no OOP, verá, que é mais elegante e claro. É mais fácil do que a programação processual!
MoneyJinn:
Utilizar a programação processual habitual no MetaTrader 5.
OOP é um desenvolvimento da programação processual.
Afinal de contas, ninguém contesta o que se pode fazer sem funções. Na verdade, é ainda mais rápido, até certo ponto. Não importa que existam fragmentos de código, que executam uma mesma acção com dados diferentes. É muito fácil de fazer uma cópia.
A utilização repetida de funções perde para o OOP. A extensão da funcionalidade é sempre a criação de uma nova função e o retrabalho do código para que seja possível chamar esta função em função de diferentes condições. Num programa OOP devidamente escrito, uma extensão é uma coisa simples que não requer refazer todo o código.
Se ao escrever programas sem OOP não sentir desconforto devido a problemas de escala, abundância de dados desnecessários e centenas de funções, sobreposição aleatória de variáveis e necessidade de "hot swapping" de funcionalidade, não precisa de OOP.
Sim, não se deve escrever no OOP por causa do OOP, nada de bom sairá. Não se deve substituir funções por aulas. Evitar os anti-padrões
OOP é um insecto, como "Niva" ou "Lada".
Utilizar programação processual regular no MetaTrader 5.
É tão acessível aqui como no MetaTrader 4.
É pena que MetaQuotes não o enfatize.
OOP é um desenvolvimento da programação processual.
Se ao escrever programas sem OOP não sentir desconforto devido a problemas de escala, abundância de dados extra e centenas de funções, sobreposição acidental de variáveis, necessidade de "hot swapping" de funcionalidade, então não precisa de OOP.
Sim, não se deve escrever no OOP por causa do OOP, nada de bom sairá. Não é necessário substituir funções por aulas.
Concordo a 100%.
Além disso, o OOP torna os projectos mais próximos da vida real, porque na vida real lidamos apenas com instâncias de objectos (casa, árvore, pessoa, máquina, ordem, etc.), ou seja, com um conjunto de propriedades e métodos :)
O que está mais próximo da realidade: uma casa virtual, uma árvore, uma pessoa ou ver o programa na sequência em que é realmente executado pelo processador?
Trata-se de uma questão religiosa. E cada um tem a sua própria escolha.
O meu posto foi uma resposta a uma pergunta de um iniciador de temas bloqueado que acabou por pagar pela sua antipatia pelo OOP,
E também como uma resposta para comerciantes comuns que tentam dominar um produto como o MT5 ou mudar para o MT5 a partir do MT4.
O meu posto foi uma resposta a uma pergunta de um iniciador de temas bloqueado que acabou por pagar o preço pela sua antipatia pelo OOP,
Uma lista de verificação para o iniciador do tópico:
Aprogramação orientada a objectos é (leia a frase ao contrário) programação orientada a objectos. Ou, programação baseada em objectos.
Por objecto entendemos código de programa (geralmente isolado de outro código), que descreveparâmetros e comportamento de objectos reais (por exemplo "máquina") ou objectos fictícios (por exemplo "grail poopkin"). Cada objecto pode ter uma vida própria e pode guisar nos seus próprios sumos. Um conjunto limitado de "canais nervosos" é utilizado para comunicar com o mundo exterior - como funções especiais com acesso externo.
Na minha opinião, a principal vantagem do OOP é que o código objecto pode ser debugado independentemente de outro código. E depois pode montar, como um mosaico, objectos mais complexos. Por exemplo, um objecto "mulher" pode incluir outros objectos: "fuselagem", "trem de aterragem", "tanques", "cockpit", etc.
O MQL5 Wizard é um bom exemplo do MQL OOP. Permite-lhe montar o Expert Advisor a partir de objectos já prontos. E estes objectos podem ser combinados.
O argumento mais trágico a favor do OOP: aqueles que compreenderam a sua essência, ficam viciados nele. É apenas mais fácil de programar; o código é mais claro e mais estruturado.
...
O argumento mais condenatório a favor do OOP: aqueles que o compreendem ficam viciados nele. É simplesmente mais fácil de programar, o código é mais compreensível e mais estruturado.
Isso é verdade, até eu dominar o OOP pareceu-me que é um lixo tão grande, que nem vale a pena misturar-se com ele.
Uma vez entendido, tudo ficou claro, já não preciso de inventar nomes únicos de variáveis,
Não tem de criar nomes únicos para variáveis, não tem de criar nomes únicos para contadores i e j e não tem de pesquisar milhares de vezes o código para descobrir onde a variável não está zerada. :o), e mais importante, tudo está mesmo à frente dos seus olhos - quando abre o programa, tudo fica imediatamente claro, aqui está a chamada do objecto, aqui está a interacção dos objectos, se quiser compreender o que o objecto está a fazer, vai para o código do objecto ...
Isso é verdade, até eu dominar o OOP pareceu-me que era uma treta tão grande que não valia sequer a pena entrar nela.
Assim que o entendi, livrei-me de tudo, já não preciso de inventar nomes únicos de variáveis,
Não precisa de criar nomes únicos para variáveis, não precisa de criar nomes únicos para contadores i e j e não precisa de pesquisar através de milhares de códigos para descobrir onde esta variável não é descartada. o), e mais importante, tudo é simples como a palma da sua mão, quando abre o programa, tudo é imediatamente compreensível, aqui está a chamada do objecto, aqui está a interacção dos objectos, se quiser compreender o que o objecto faz, vai para o código do objecto
+10
Eu até argumentaria com a afirmação de que não se deve usar o OOP para pequenos projectos.
Parece-me que o OOP deve ser utilizado sempre que possível - o código aumenta um pouco, mas a sua transparência aumenta muitas vezes.
+10
Eu até argumentaria com a tese de que para pequenos projectos não há necessidade de utilizar o OOP.
Parece-me que o OOP deve ser empurrado sempre que possível - o código prolonga-se de forma insignificante, mas a sua transparência aumenta muitas vezes.
Sou um apoiante do OOP, pois compreendi a conveniência de programar de baixo para cima. Desde interfaces de interacção de objectos até à implementação de classes. Todos aqueles que começam por implementar aulas não estão a escrever em OOP adequado, estão a escrever invólucros funcionais. Tais invólucros não fornecem mais do que um espaço de nomes conveniente para variáveis e funções. Esta é a abordagem habitual da biblioteca. Mas mesmo este mínimo serve a algumas pessoas e elas dizem orgulhosamente "Eu escrevo no OOP", que é o seu direito, no entanto.
Há programadores qualificados e fundadores de correntes inteiras em software moderno que têm experiência suficiente para criticar o paradigma OOP. Este é um tema antigo e, em princípio, tudo tem sido discutido ao mais pequeno pormenor há muito tempo, quando e onde se perdeu o que se perdeu:
http://blogerator.ru/page/oop_why-objects-have-failed
Aqui está a resposta dos apoiantes do OOP
http://bugtraq.ru/library/programming/objectshavenotfailed.html
Comparação de velocidade C++ (pequeno teste) Programação orientada a objectos e processual (+ diferentes compiladores)
https://www.mql5.com/ru/forum/132434/page3