Regras de estrutura. Aprender a estruturar programas, explorar possibilidades, erros, soluções, etc. - página 10
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
Não sou estranha à programação do Estado e utilizei-a eu própria durante vários anos. Contudo, após algum tempo de utilização deste método, decidi abandoná-lo e desenvolvi um modelo mais transparente, mais simples e mais adequado ao comércio na sua base.
Leia atentamente este artigo: Programação automática como uma nova forma de criar sistemas de comércio automatizados
Depois leia atentamente estes comentários sobre o assunto.
Depois, muito, muito comoventemente, contemple uma placa de má aparência do artigo, e pense no que ela poderia significar:
Se, depois de ler tudo isto, ainda estiver a dizer: "Uau! A programação do Estado é tão fixe!" - bem, conte com isso.
Acrescentaria que o principal problema da programação do Estado são situações que produzem muitos modos inúteis (ver coluna N Estado). Na programação do Estado, cada modo deve descrever as suas próprias regras separadamente. Vamos explicar pelo exemplo, digamos que estamos no modo Comprar. Tudo está bem até que o robô decida abrir mais uma posição. E porque não? As condições de saída da antiga posição não foram satisfeitas e é demasiado cedo para a fechar, enquanto um novo sinal não deve ser perdido. E é aqui que começam os problemas, porque no momento da chegada de um novo sinal o robô está no modo Comprar, enquanto as regras para abrir uma nova posição estão no modo Estado (esperar e procurar por novos sinais de entrada). Agora, no modo Comprar, temos de re-descrever as mesmas regras de abertura de posição que são utilizadas no modo Estado. E se uma nova posição for oposta em direcção oposta (sebe)? Esta posição está aberta, mas o que fazer com ela? Afinal, a sua lógica de gestão é descrita no modo Vender, enquanto o robô está no modo Comprar. Podemos simplesmente mudar para o modo de Venda, mas o que fazer com a posição de Compra restante? De um modo geral, neste caso temos de escrever mais um modo inútil como BuyAndSell. A redundância de modos produz mais uma situação: uma e a mesma acção é executada por diferentes secções de código. Em suma, para aqueles que gostam de confusão de programação exponencial, isto é o melhor.
"É assim que é Mihalych" (c)... É isso que também estou a insinuar.
(fcplm)
Nem pensar.
Estava apenas a pensar que se a MQL5 suportasse herança múltipla e uma classe pudesse declarar métodos abstractos, abriria uma forma de utilizar interfaces, o que seria óptimo para grandes projectos.
Os métodos abstractos não são explicitamente proibidos (utilizo frequentemente notações alternativas),
E a herança múltipla seria uma enorme mais-valia.
Os métodos abstractos não são explicitamente proibidos.
Para citar Rosh: como é que isto o ajuda a serrar lenha?
A FAQ de Von está sentada no quadruplolet e não quer saber de métodos abstractos e herança múltipla.
Não importa se haverá métodos abstractos ou não, de qualquer forma, a tarefa de estruturação do projecto não será resolvida.
A propósito, quanto mais variantes de implementação de uma e mais difícil é escolher qual a variante a utilizar.
Assim, acontece que o programador fica muitas vezes preso na tarefa da beleza do código. É uma arte para o bem da arte.
Tenho notado, geralmente (falando por mim), que quanto mais selos de planeamento de projectos, mais fácil é.
Depois pode mudar, modificar, re-modificar, modificar em demasia,
Mas a estrutura inicial (mesmo que não seja grande) dá o tom para toda a construção.
Para citar Rosh: Como é que isto o ajuda a serrar lenha?
Depois pode mudar, re-modificar, re-modificar, sobre-modificar,
mas a estrutura inicial (mesmo que não seja grande) define o tom para toda a construção.
A velocidade de serragem da lenha vai aumentar.
Se já tem uma ideia clara de como e como deve ser - provavelmente pode fazer tudo de forma inteligente na MQL4.
E se não existir tal noção - significa que haverá muitas mudanças e adições. E a herança múltipla permite alterações com custos mínimos.
Concordo com os métodos abstractos - é apenas uma boa forma de gravação.
A velocidade da serragem da lenha aumentará.
Se já tem uma ideia clara de como e como deve ser - provavelmente pode fazer tudo de forma inteligente na MQL4.
E se não tiver essa ideia - isso significa muitas mudanças e adições. E a herança múltipla, em particular, permite fazer alterações com custos mínimos.
Hoje em dia, tenta-se abandonar a herança em favor da inclusão. Consegue imaginar a atitude em relação à herança múltipla?
FAQ:
Nem pensar.
Não é. Usando um interruptor... e usando um padrão de máquina de estado são duas coisas diferentes. Pode ver no texto que não existe um padrão, tal como no artigo que citou.
Lê-se algo como "Inventei um sistema vencedor único..." e depois uma declaração de martin tortas.