O POE para crianças em idade escolar. - página 6
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
OK. Dê sua definição de "getter".
não é um cavalo
não é um cavalo.
Pensei que estava lidando com alguém que poderia explicar o que ele sabe. Mas aqui, mesmo no nível das definições, há problemas.
Pensei que estava lidando com alguém que pode explicar o que ele sabe. Pensei que estava lidando com alguém que poderia explicar o que ele sabe.
Sim, fantasie como quiser, há muito compreendo tudo com alguns de vocês aqui também, prontos para congelar suas orelhas para apesar de sua avó.
Vocês podem fantasiar o quanto quiserem, há muito tempo também compreendi tudo com alguns de vocês aqui.
Tudo está claro para você. Você simplesmente não consegue explicar))
Tudo está claro para você. Você simplesmente não consegue explicar).
Continue a congelar suas orelhas para apesar de sua avó.
Tenho lido desde o primeiro minuto de sua criação.
ler não é suficiente, imho, você precisa tentar definir tarefas e escrever em estilo de procedimento, então (não é difícil) reescrever esta tarefa em estilo OOP
Como a TC tem escrito repetidamente, o OOP permite que você aumente rapidamente a tarefa, acelere o desenvolvimento e reduza o número de erros na escrita do programa
Para a MQL: Um dos meus problemas menos favoritos é o fechamento parcial de uma série de pedidos; em um estilo de programação processual, após chamar uma sub-rotina que fechará um pedido, o tratamento de erros precisa ser organizado - o que fazer se eu não conseguir fechar todos os pedidos parcialmente em uma chamada? - o servidor não permitiu o fechamento parcial? - Eu fiz esta pergunta no início do ano, bem, como de costume, em 99% dos casos todas as soluções comuns foram reduzidas à análise de comentários de pedidos - como lido lá, o servidor escreverá tudo lá.....imho, não profissional
No estilo OOP este problema é resolvido "em 2 cliques", chamamos o método de fechamento parcial do pedido, e os dados sobre o estado do pedido - ticket, necessidade de sua modificação..... e métodos de trabalho com o pedido são armazenados na classe ORDER - solução com máxima flexibilidade e escalabilidade para as próximas tarefas, imho
o mesmo se aplica a tarefas com gráficos em MQL - se você tem uma etiqueta de texto, não é um problema trabalhar com ela, mas se você tem 10-100 etiquetas? - E se você precisar mudar o esquema de cores, seletivamente para alguns rótulos "coral", e para outros "pérola com botões"? .... e depois de uma semana levou para adicionar mais 3 botões.... e uma semana depois outros 10 botões precisavam ser removidos....
ZS: outro tópico de luta contra moinhos de vento .... não, lembrou-se de alguém (esqueceu seu sobrenome ))) ) - quem disse que a terra é redonda e depois ele foi queimado? )))) - é assim que se parece a luta contra o analfabetismo e/ou a ampliação dos horizontes de cada um
ler não é suficiente, imho, você precisa tentar definir tarefas e escrever em estilo de procedimento, então (não é difícil) reescrever esta tarefa em estilo OOP
Como a TC tem escrito repetidamente, o OOP permite que você aumente rapidamente a tarefa, acelere o desenvolvimento e reduza o número de erros na escrita do programa
Para a MQL: Um dos meus problemas menos favoritos é o fechamento parcial de uma série de pedidos; em um estilo de programação processual, após chamar uma sub-rotina que fechará um pedido, o tratamento de erros precisa ser organizado - o que fazer se eu não conseguir fechar todos os pedidos parcialmente em uma chamada? - o servidor não permitiu o fechamento parcial? - Eu fiz esta pergunta no início do ano, bem, como de costume, em 99% dos casos todas as soluções comuns foram reduzidas à análise de comentários de pedidos - como lido lá, o servidor escreverá tudo lá.....imho, não profissional
No estilo OOP este problema é resolvido "em 2 cliques", chamamos o método de fechamento parcial do pedido, e os dados sobre o status do pedido - ticket, necessidade de sua modificação..... e métodos de trabalho com o pedido são armazenados na classe ORDER - solução com a máxima flexibilidade e escalabilidade para as próximas tarefas, imho
o mesmo se aplica a tarefas com gráficos em MQL - se você tem uma etiqueta de texto, não é um problema trabalhar com ela, mas se você tem 10-100 etiquetas? - E se você precisar mudar o esquema de cores, seletivamente para alguns rótulos "coral" e para outros "perolados com botões"? .... e depois de uma semana levou para adicionar mais 3 botões.... e uma semana depois outros 10 botões precisavam ser removidos....
ZS: outro tópico de luta contra moinhos de vento .... não, lembrou-se de alguém (esqueceu seu sobrenome ))) ) - quem disse que a terra é redonda e depois ele foi queimado? )))) - é assim que se parece o combate ao analfabetismo e/ou a ampliação dos horizontes
Na minha opinião, em mql o conjunto de problemas a serem resolvidos via OOP é muito estreito. A linguagem em si, me parece, não é nada além de OOP em C++ ou o que quer que seja. E este OOP é oferecido na forma de uma biblioteca padrão. E a este OOP é sugerido acrescentar, caso contrário eu não diria, outro OOP. E depois outro passo... Disse Warlock, embora zangado, mas benevolente, para minhas tarefas OOP é como uma mesa giratória para cães. E de que adianta definir um problema e depois implementá-lo através do OOP se esse problema pode ser resolvido em estilo processual sem nenhum problema.
Por exemplo, pegue .mqh do fxsaber`a para escrever códigos para MT5, bem como para MT4. Talvez alguém precise disso, mas olha quem... Para alguém que não quer ou absolutamente não pode dominar o mql5. Ou tome iCanvas de Nikolay ... Esqueci seu sobrenome. Parece ser uma biblioteca útil, mas não é fácil entendê-la, e não há documentação, mesmo uma pequena descrição. Não é uma reclamação, desculpe Nikolay, é um fato. Assim, quando decidi tentar escrever uma etiqueta gráfica, foi mais fácil escrevê-la sem referência à biblioteca padrão ou à biblioteca do Nikolai.
Na minha opinião, a mql tem um conjunto muito estreito de tarefas que precisam ser resolvidas através do OOP. O idioma em si me parece ser nada mais do que um OOP em C++ ou algo assim. E este OOP é oferecido na forma de uma biblioteca padrão. E a este OOP é sugerido acrescentar, caso contrário eu não diria, outro OOP. E depois outro passo... Disse Warlock, embora zangado, mas benevolente, para minhas tarefas OOP é como uma mesa giratória para cães. E de que adianta definir um problema e depois implementá-lo através do OOP se esse problema pode ser resolvido em estilo processual sem nenhum problema.
Infelizmente você está 90% certo, mas apenas porque as estratégias comerciais que os comerciantes pedem para escrever .... Francamente falando, eles são primitivos. Houve alguma excitação quando se tornou possível criar painéis gráficos de qualidade em MQL, mas acabou por não ser necessário aos usuários finais - este é o problema da indústria, o público, embora motley, está interessado nele .... eles querem apenas um botão: dinheiro ...
Por exemplo, tome .mqh de fxsaber`a para escrever códigos para MT5, bem como para MT4. Talvez alguém precise disso, mas olha quem ... Aquele que não quer ou absolutamente não pode dominar o mql5.
Estou usando esta biblioteca, porque preciso do mt5, mas não quero passar meu tempo estudando o sistema de pedidos, mas tentei pedir uma ou duas vezes no tópico de novatos do MT5... Eu realmente não quero passar meu tempo estudando o sistema de pedidos, mas tentei algumas vezes no ramo de novatos do MT5... Sem resultados - na verdade, não há ninguém lá que saiba como funciona o sistema de pedidos e responda minhas perguntas... ...então, "Jumblebug" para dizer de forma suave...
Ou tome iCanvas de Nikolay ... Eu esqueço seu sobrenome, você entende. Parece ser uma biblioteca útil, mas não é fácil entendê-la, e não há documentação, mesmo uma pequena descrição. Não é uma reclamação, desculpe Nikolay, é um fato. Assim, quando decidi tentar escrever uma etiqueta gráfica, foi mais fácil escrevê-la sem referência à biblioteca padrão ou à biblioteca do Nikolai.
usou a biblioteca da @Nikolai Semko algumas vezes - nada comum, basta conectá-la e usá-la... o princípio é como 99% dos EAs lançados diariamente no KB - o moderador não se preocupa com o sistema de pedidos lá, certo? - o AdS é escrito na forma de OOP e ele produz todos os Expert Advisors que ele pensa
Na minha opinião, a mql tem um conjunto muito estreito de tarefas que precisam ser resolvidas através do OOP. O idioma em si me parece ser nada mais do que um OOP em C++ ou algo assim. E este OOP é oferecido na forma de uma biblioteca padrão. E a este OOP é sugerido acrescentar, caso contrário eu não diria, outro OOP. E depois outro passo... Disse Warlock, embora zangado, mas benevolente, para minhas tarefas OOP é como uma mesa giratória para cães. E de que adianta definir um problema e depois implementá-lo através do OOP se o problema pode ser resolvido em estilo processual sem nenhum problema.
Por exemplo, pegue .mqh do fxsaber para escrever os códigos para MT5 como para MT4. Talvez alguém precise, mas veja quem. Aqueles que não querem ou absolutamente não podem dominar o mql5. Ou tome iCanvas de Nikolay ... Esqueci seu sobrenome. Parece ser uma biblioteca útil, mas não é fácil entendê-la, e não há documentação, mesmo uma pequena descrição. Não é uma reclamação, desculpe Nikolay, é um fato. Assim, quando decidi tentar escrever uma etiqueta gráfica, foi mais fácil escrevê-la sem referência à biblioteca padrão ou à biblioteca do Nikolai.
Aaplicação do OOP implica um nível de complexidade de tarefas, muito maior do que em algotrading. É por isso que existem disputas. O OOP é necessário para programadores e desenvolvedores profissionais para lidar com programas complexos. Há pouco espaço para uma abordagem tão séria. É errado explicar o significado do OOP em pequenos exemplos. O sentido do OOP está em trabalho de larga escala com uma enorme quantidade de dados e funções. A diversidade de dados requer separação e classificação, e então há a relevância do encapsulamento de descrição, herança de propriedades e métodos entre classes hierarquicamente separadas.
Isto não faz sentido em tarefas pequenas.