Alguém criou um sistema comercial automatizado de sucesso? Qual é o seu conselho? - página 16
![MQL5 - Linguagem para estratégias de negociação inseridas no terminal do cliente MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Ótimo! E quanto ao lucro com o OOP. Irá logo depois que você aprender?
O OOP lhe dá a capacidade de escrever um código compacto, claro e elegante. Você gasta várias vezes menos tempo escrevendo, modificando e depurando códigos, o que é muito caro. Você pode construir um sistema comercial muito mais sofisticado e experimentar muito mais opções comerciais. É claro, se você não tem nenhuma idéia para um robô rentável - então é melhor não fazer nada. Além disso, não se esqueça da probabilidade de perda direta em caso de erros, cuja probabilidade em bom código OOP é muito menor.
O OOP lhe dá a capacidade de escrever um código compacto, claro e elegante.
Não tem.
Este não é o caso.
Bem, se você definir uma tarefa para complicá-la deliberadamente, então sim, há mais oportunidades para complicá-la deliberadamente com o OOP.
Mas se você não se tornar como o Macaco com Óculos, você fica muito mais claro, mais estruturado e com código de manutenção com o OOP.
Eu não sou contra a OOP, amigos. Gosto de sua idéia de objeto. E eu o utilizo parcialmente, mas na forma de estruturas, ou melhor, de uma série de estruturas. É suficiente no comércio para armazenar todos os dados de um gráfico e não executar loops em cada barra. Mas acho que isso é tudo o que precisamos. Naturalmente, pode-se escrever tudo no OOP, aqueles que estão acostumados a ele. Mas elas estão longe de ser lucrativas como as processuais. Toda a questão está em um sistema lucrativo, se você o tem, você pode escrevê-lo por goto-code :)
O tema do ramo está pairando sobre a forma de resolvê-lo.
E eu o uso em parte, embora sob a forma de estruturas, ou melhor, de uma série de estruturas.
Em Java tem até seu próprio nome: POJO (Plain Old Java Object)
;)
O código OOP é visivelmente mais claro, mais estruturado e mais fácil de manter.
Este não é sempre o caso e depende não do OOP, mas da limpeza do código, da nominação.
Eu não sou contra a OOP, amigos. Gosto de sua idéia de objeto. E eu o utilizo parcialmente, mas na forma de estruturas, ou melhor, de uma série de estruturas. É suficiente no comércio para armazenar todos os dados de um gráfico e não executar loops em cada barra. Mas acho que isso é tudo o que precisamos. Naturalmente, pode-se escrever tudo no OOP, aqueles que estão acostumados a ele. Mas elas estão longe de ser lucrativas como as processuais. Toda a questão está em um sistema lucrativo, se você o tem, você pode escrevê-lo por goto-code :)
O tema do ramo está pairando sobre a forma de resolvê-lo.
O uso de estruturas não é OOP. Todos os benefícios do OOP começam quando você começa a usar os padrões OOP. Herança, singletons, facetas de objetos, classes de interface, etc. Além disso, você não pode passar sem o OOP se tiver mais de 2 pessoas em sua equipe. Por exemplo:
Em seguida, ou você mesmo ou dê 3 pessoas para escrever sinais, por exemplo, para 3 indicadores diferentes:
O local onde o sinal é usado é suficiente para fazer:
Você, como señor, está completamente abstraído das implementações de corpos funcionais. A implementação e qual indicador é utilizado não é importante para você. Basta usar o check_signal e pronto. Neste exemplo, uma função é utilizada. E se há muitas funções em uma classe - você tem que inserir o switch onde quer que a implementação dependa da configuração ou outra escolha. Além disso, se você utiliza um banco de dados ou, digamos, um arquivo de registro em um monte de lugares - você tem que fazer uma variável global e controlar seu estado em todas as etapas (se o arquivo ou banco de dados está aberto, etc.). Caso você use singleton para esta finalidade - você pode ter certeza de que onde quer que você use arquivo de log/objeto de base - sempre haverá uma cópia do objeto onde você poderá reabrir base/arquivo, usar bandeiras de estado, fazer log em buffer para não escrever em disco em todas as saídas, etc. Se você tem mais de 10.000 linhas de código, a funcionalidade se torna um inferno para o desenvolvedor. E em meio ano, quando você tiver esquecido metade de seu código, será um inferno vivo reelaborá-lo. Além disso, um bom projeto OOP permite adicionar novas funcionalidades ou editar a antiga sem medo de que tudo vá para o inferno se você mudar alguma coisa em algum lugar.
Qual é a diferença no OOP em 5 e 4? Século das Luzes. A diferença no ambiente de estoque é óbvia. Bem, as barras são numeradas a partir do final. Não vejo nenhuma outra diferença óbvia no idioma.
Como mínimo, um monte de funções telescópicas foram finalmente eliminadas e, mais importante ainda, uma biblioteca padrão com um grande número de classes úteis foi adicionada.
Como mínimo, finalmente se livrou de um monte de funções telescópicas e o mais importante, uma biblioteca padrão com um grande número de classes úteis foi adicionada.
especialmente Object.mqh
diretamente dos livros que você, por sorte, cita...padrão brilhante :-)
O tópico não é sobre como você dominou bem o curso OOP e aprendeu a defendê-lo... na minha opinião, é um domínio de merda
De qualquer forma, pegue seus livros didáticos e vá para a escola amanhã.