Que código OOP pode fazer que o código de procedimento não pode? - página 4
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
Você realmente espera que alguém profissional esteja postando uma biblioteca concorrente, exatamente como uma "prova"? ;) Eu poderia postar um link para algo pronto que não pode ser vendido no mercado aqui, mas Alain vai me chutar se eu o fizer ;) Você pode visitar meu perfil e dar uma olhada na foto na parede para ter uma idéia ou me deixar cair uma pm.
Outra plataforma? Você não encontrará nenhuma outra plataforma com um compilador tão poderoso. De jeito nenhum.
@James Cater - que muito obrigado por seus comentários.
Existem outras plataformas lá fora além da MT, desde que o compilador seja mais ou menos poderoso, eu realmente não me importo, desde que eu possa escrever um código simples.
O que lhe falta aqui é educação, todos nós ainda estamos aprendendo, alguns estão apenas mais longe do que outros. Tanto quanto sei, isto não é um concurso, mas um lugar para a troca de conhecimento e apoio.
E, a propósito, não acredito que ninguém neste fórum escreva um milhão de linhas de programa.
Você perdeu o ponto Dirk. Pessoas não especializadas querem exemplos de código simples e claros, o que na verdade era meu objetivo com este tópico. Mas isso parece completamente além da compreensão dos especialistas.
Você disse que a chave acontece em todos os idiomas. Os últimos idiomas tentam simplificar as coisas para as pessoas com menos conhecimentos de codificação podem ser adicionados ao grupo de "codificadores". O melhor exemplo é a pseudo-linguagem HTML. E esse é o grande erro. Quando o MT5 foi desenvolvido, muitos "novatos" culpam o estilo OOP porque era difícil. Mas a verdade é que todo trabalho tem seus profissionais. Se você quer melhorar uma plataforma, você a tem complexa. Mais recursos, mais flexibilidade. Deixe as pessoas sem conhecimento de código tentarem fazê-lo é como se alguém sem saber na construção de casas tivessem feito uma. Será um desastre.
A duração dos projetos depende do codificador. Minha biblioteca é de tamanho médio para a linguagem MQL. Outros precisam apenas de pequenas bibliotecas para criar ferramentas. No meu caso, prefiro gastar tempo na criação de uma estrutura para economizar tempo e simplificar o desenvolvimento no futuro. Se você tiver feito UIs complexas ou reutilizar código para outros projetos é a maneira mais inteligente.
Você disse que a chave acontece em todos os idiomas. Os últimos idiomas tentam simplificar as coisas para as pessoas com menos conhecimentos de codificação podem ser adicionados ao grupo de "codificadores". O melhor exemplo é a pseudo-linguagem HTML. E esse é o grande erro. Quando o MT5 foi desenvolvido, muitos "novatos" culpam o estilo OOP porque era difícil. Mas a verdade é que todo trabalho tem seus profissionais. Se você quer melhorar uma plataforma, você a tem complexa. Mais recursos, mais flexibilidade. Deixe as pessoas sem conhecimento de código tentarem fazê-lo é como se alguém sem saber na construção de casas tivessem feito uma. Será um desastre.
A duração dos projetos depende do codificador. Minha biblioteca é de tamanho médio para a linguagem MQL. Outros precisam apenas de pequenas bibliotecas para criar ferramentas. No meu caso, prefiro gastar tempo na criação de uma estrutura para economizar tempo e simplificar o desenvolvimento no futuro. Se você tiver feito UIs complexas ou reutilizar código para outros projetos é a maneira mais inteligente.
Então as pessoas não podem adquirir conhecimentos?
Procedural vs OOP é um debate inútil, 3 anos atrás já foi discutido e minha resposta é completamente válida, nada mais foi dito aqui :
Fórum sobre comércio, sistemas automatizados de comércio e teste de estratégias comerciais
Programadores: O que é sua perferência: OOP vs Procedural
Alain Verleyen, 2013.06.11 13:11
Sua pesquisa não tem opção para aqueles que não preferem nada. Isto não é apenas uma questão de preferência, que não faz sentido usar o OOP para um pequeno roteiro ou mesmo um simples EA. OOP sempre adiciona trabalho e só é vantajoso para projetos complexos e reutilização de código (mesmo código usado em vários projetos). Complexo não é o mesmo é grande, se alguém tem um projeto grande mas relativamente simples ,isto não significa automaticamente que ele deve usar OOP.
Você pode ver o grande potencial do OOP com MQL5 Wizard desenvolvido pela Metaquotes, seria muito difícil desenvolver tal ferramenta com programação de procedimentos,embora seja viável .
O OOP deve ser usado:
A partir de agora não aceitarei nenhum post que não seja concreto, sem exemplo de código para demonstrar por que e como o OOP deve ser melhor utilizado nos casos acima.
Procedural vs OOP é um debate inútil, 3 anos atrás já foi discutido e minha resposta é completamente válida, nada mais foi dito aqui :
O OOP deve ser usado:
A partir de agora não aceitarei nenhum post que não seja concreto, sem exemplo de código para demonstrar por que e como o OOP deve ser melhor utilizado nos casos acima.
Eu li todo este tópico, e acho isto interessante, mas o código da máquina não é procedimental? Então idiomas de alto nível, e o OOP incluído, todos eles no final são traduzidos em procedimento no compilador, certo? Se todos os idiomas forem traduzidos em código de máquina de procedimento, então podemos dizer que tudo pode ser feito em procedimento, se o programador adquirir as habilidades, por favor, alguém me corrija se eu estiver errado.
Tudo pode ser feito em teoria processual. Não é prático.
Um tijolo é construído a partir de milhares de milhares de partículas de areia, para que se possa construir uma casa sem tijolos, apenas a partir da areia.
Mas ninguém está sequer tentando quando se tem tijolos.
Um avião é construído com peças prontas - asas, rodas, assentos, computadores, etc. Todas elas são feitas de metal, plástico ou vidro na extremidade. Mas ninguém constrói um avião a partir de vidro puro, plástico e metal.
Para o debate em geral (em resposta ao Alain e aos outros): Tomemos o CArrayObj - um conjunto de objetos. Só isto é suficiente para responder qual é o poder do OO (que é muito mais do que isso). Ele pode armazenar um conjunto de quaisquer objetos - como indicadores, por exemplo.
E sem nenhum esforço, faça coisas complexas para todos esses diferentes indicadores. E se você agora quer um novo poder para isto, por exemplo, você quer saber quando um buffer de indicadores é cruzado, você só tem que colocar o método no CIndicator, é isso. E assim por diante. Como você faria isso no procedimento?
E isto pode ser feito em todos os aspectos - Estratégias, Negócios, Acordos, Sinais - o que quer que seja.
Tudo pode ser feito em termos teóricos de procedimento. Não é prático.
Um tijolo é construído a partir de milhares de milhares de partículas de areia, para que se possa construir uma casa sem tijolos, apenas a partir da areia.
Mas ninguém está sequer tentando quando se tem tijolos.
Um avião é construído com peças prontas - asas, rodas, assentos, computadores, etc. Todas elas são feitas de metal, plástico ou vidro na extremidade. Mas ninguém constrói um avião a partir de vidro puro, plástico e metal.
Para o debate em geral (em resposta ao Alain e aos outros): Tomemos o CArrayObj - um conjunto de objetos. Só isto é suficiente para responder qual é o poder do OO (que é muito mais do que isso). Ele pode armazenar um conjunto de quaisquer objetos - como indicadores, por exemplo.
E sem nenhum esforço, faça coisas complexas para todos esses diferentes indicadores. E se você agora quer um novo poder para isso, por exemplo, você quer saber quando um buffer de indicadores é cruzado, você só tem que colocar o método no CIndicator, é isso. E assim por diante. Como você faria isso no procedimento?
E isto pode ser feito em todos os aspectos - Estratégias, Negócios, Acordos, Sinais - o que quer que seja.
Este tópico foi intencionalmente provocador, porém a resposta à pergunta principal (o que pode o OOP pode fazer que o código de procedimento não pode) NÃO É OBSERVAÇÃO.
O OOP certamente não é a única maneira de construir e usar tijolos. Eles são, pelo menos, a mesma maneira de criar código ruim no OOP do que no código de procedimento (e muito provavelmente mais maneiras). Basta olhar para a "Biblioteca Padrão" fornecida pela Metaquotes, que na verdade está longe de ser "padrão".
O OOP versus procedural é inútil e um debate interminável. Uma mais útil deveria ser "Como produzir código de qualidade? Com e sem OOP, com e sem procedimento, com e sem qualquer paradigma de programação". Se sua necessidade é construir uma casa de madeira, você não precisa de tijolos, mas precisa que ela seja uma casa boa, sólida e confiável.
Tudo pode ser feito em teoria processual. Não é prático.
Um tijolo é construído a partir de milhares de milhares de partículas de areia, para que se possa construir uma casa sem tijolos, apenas a partir da areia.
Mas ninguém está sequer tentando quando se tem tijolos.
Um avião é construído com peças prontas - asas, rodas, assentos, computadores, etc. Todas elas são feitas de metal, plástico ou vidro na extremidade. Mas ninguém constrói um avião a partir de vidro puro, plástico e metal.
Para o debate em geral (em resposta ao Alain e aos outros): Tomemos o CArrayObj - um conjunto de objetos. Só isto é suficiente para responder qual é o poder do OO (que é muito mais do que isso). Ele pode armazenar um conjunto de quaisquer objetos - como indicadores, por exemplo.
E sem nenhum esforço, faça coisas complexas para todos esses diferentes indicadores. E se você agora quer um novo poder para isto, por exemplo, você quer saber quando um buffer de indicadores é cruzado, você só tem que colocar o método no CIndicator, é isso. E assim por diante. Como você faria isso no procedimento?
E isto pode ser feito em todos os aspectos - Estratégias, Negócios, Acordos, Sinais - o que quer que seja.
Em seu exemplo, quando você codifica OO e clica em compilar, ele irá gerar o código da máquina. Mas este código de máquina é de procedimento ou não? Eu realmente não sei a resposta, alguém aqui sabe? Se o código de máquina é de procedimento, então você pode chamar OO apenas uma linguagem de nível superior, que torna mais fácil codificar apenas, mas nada de especial, de modo que um programador C habilidoso pode fazer o mesmo trabalho que um programador OO, na verdade, ele pode ser ainda melhor otimizado. Então, minha pergunta, ex código é prodedural ou não?