Regras de estrutura. Aprender a estruturar programas, explorar possibilidades, erros, soluções, etc. - página 18
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
Oh, Vladimir, não é tão fácil com o seu circuito. Está a dizer que só precisa de reescrever o condutor? Bem, contei muito mais peças dependentes de plataformas:
Como obter a história do mercado e a história do comércio? E a informação sobre a posição actual não será, por acaso, retirada do terminal? E se tiver de implementar o módulo de volatilidade - mais um API dependente da plataforma?
Vai escrever adaptadores? Quantos deles existirão? Para o histórico do mercado - um adaptador, para o histórico de negociação - outro, para trabalhar com as posições - um terceiro. Assim, no final, haverá o dobro de módulos, e a mesma quantidade de código dependente da plataforma.
Não é assim que eu vejo o problema.
Apenas tudo o que é vermelho é bastante estável, tudo o que vem da plataforma não muda ao longo dos anos, se precisar de outra plataforma, há também uma API bem estabelecida, reescreva sem problemas.
Mas todos os módulos com setas verdes são os seus próprios, e quase sempre activos no retrabalho (não há limite para o ideal).
O forecaster direccional foi escrito, depois veio a nova ideia para aprofundar e expandir, bem, como agora é comprar, mas temos de nos preparar para vender, reduzir lentamente o volume.
Assim, comecei a utilizar dois módulos.
MM Corrector é também um esquema dinâmico, agora funciona com posições, depois de repente teve uma ideia e decidiu mudá-lo para posições longas (entrada suave no mercado).
Market Driver deve ser estável porque tem saída para API dependente de plataforma, portanto a formalização é clara, mas haverá muita torção, porque API fornece muitas possibilidades.
Não é assim que eu vejo o problema.
Apenas tudo o que é vermelho é bastante estável, tudo o que vem da plataforma não muda durante anos, se precisar dela para outra plataforma há também uma API bem estabelecida, a reescrita não é um problema.
Uma das ideias importantes no esquema não é o número de partes dependentes da plataforma, mas a sua localização rigorosa. Ou seja: o próprio TS (preditores + módulos MM) - é um desenho independente da plataforma, mas as fontes de dados são indicadores e motor de mercado, respectivamente dependentes (histórico comercial, alimentado à entrada do corrector de recomendações - é também essencialmente o indicador).
A consequência - uma zona de intervenção claramente limitada, claramente distinguível e não sobreposta em
1. Migração.
2. Melhoramento do TS, em particular, a escalada.
Mas todos os módulos com setas verdes são os seus próprios, e quase sempre um redesenho activo (não há limite para o ideal).
O forecaster direccional foi escrito, depois veio a nova ideia para aprofundar e expandir, bem, como agora é comprar, mas precisamos de nos preparar para vender, reduzir lentamente o volume.
Assim, comecei a utilizar dois módulos.
O MM Corrector é também um esquema dinâmico, agora funciona com a posição, depois, de repente, tornou-se sensato e decidiu mudá-lo para a equidade (entrada suave no mercado).
O Market Driver deve ser estável porque tem saída para o API dependente da plataforma, portanto a formalização é clara, mas haverá muita confusão porque o API fornece muitas características.
Ninguém prometeu ausência de complicações :) Mas pense se todas essas chamadas API directas não estão localizadas no driver, mas misturadas com códigos de preditores e MM-modules.............
;)
Nikolay, o seu posto é muito sensato, contudo comprometo-me a defender o esquema proposto (a sua universalidade).
Concordo, quero apenas esclarecer (aproveitando a oportunidade) para Vasily. Uma das ideias importantes no esquema não é o número de partes dependentes da plataforma, mas a sua localização rigorosa. Ou seja: o próprio TS (preditores + módulos MM) - é um desenho independente da plataforma, mas as fontes de dados são indicadores e motor de mercado, respectivamente dependentes (histórico comercial, alimentado à entrada do corrector de recomendações - é também essencialmente o indicador).
A consequência - uma zona de intervenção claramente limitada, claramente distinguível e não sobreposta em
1. Migrações.
2. Melhoramento do TS. Em particular, a escalada.
Contudo, se nos cingirmos cuidadosamente à divisão das partes do sistema dependentes/independentes da plataforma, então, por exemplo na nossa situação actual, podemos facilmente apoiar o desenvolvimento de EAs para ambas as plataformas (MT4/5), o que seria um incómodo nos sistemas de negociação dependentes da plataforma.Pode haver qualquer número de módulos dentro dos componentes marcados no esquema. Isto é normal. Penso que apenas a sua disposição clara de condutas é útil. Que não deve ser misturada dentro do código sem necessidade absolutamente inevitável. ou seja Deve evitar tanto quanto possível o baralhamento, o que lhe permite ter sempre pontos de ancoragem bem definidos e convenientes do módulo ao escalar em direcção a multiferramentas.
Ver acima. // Mas a entrada do MM corrector é o ponto mais conveniente para integrar uma nuvem de forecasters de moeda única (mais precisos) numa cozinha de múltiplas moedas (multi-instrumental).Ninguém prometeu total ausência de complexidades :) Mas pense se todas estas chamadas API directas não estão localizadas no driver, mas misturadas com códigos de preditores e MM-modules.............
;)
OK, vamos usar isso como base (mas adicionar um módulo de paragem, parece razoável e ninguém tem qualquer objecção),
e pensar no que mais falta neste esquema, ou refazê-lo.
OK, tomemos como base (basta adicionar um módulo para trabalhar com paragens, parece razoável e ninguém tem qualquer objecção),
e pensar sobre o que mais falta neste circuito, ou retrabalhá-lo.
Pensarei no reaperfeiçoamento do trabalho (deixá-lo fermentar).
A falta é mais óbvia - este esquema obviamente carece do GUI (subsistema de monitorização/controlo visual). Quero desenvolver um esquema unificado (e conveniente!) de interacção do Expert Advisor com o GUI. Até agora, sou espontâneo neste assunto, o que realmente me irrita. Gostaria de atingir o mesmo objectivo (abstracção total dos dados em ambas as direcções). Foi por isso que sugeri a tarefa de interface EA/GUI para a formação, estou interessado nela em termos mercantis, queria obter algumas ideias do público.
Pode haver qualquer número de módulos dentro dos componentes destacados no esquema. Isto é normal. Acho que só é útil ter a sua disposição clara de condutas, que não devem ser baralhadas dentro do código sem necessidade absolutamente inevitável, isto é Isto permite-lhe ter sempre pontos de acoplagem bem definidos e convenientes ao escalar para multiferramentas. Olhe para o diagrama a partir deste ângulo e irá encontrá-lo você mesmo.
A expansão ilimitada do módulo conduz a sérios problemas no futuro. Tem a lógica do Expert Advisor praticamente dispersa em diferentes módulos. Os próprios módulos irão interagir uns com os outros, e não há garantia de que as ligações entre eles não se tornem um emaranhado. Imho, todos os quadrados marcados a verde são elementos de um sistema de comércio. A sua decomposição em diferentes módulos viola um dos principais princípios de programação: o encapsulamento de dados e métodos dentro de uma tarefa.
Desde que todos começaram a publicar os seus próprios esquemas, eu também vou continuar. Desta vez é um esquema ainda mais abstracto:
As setas negras descrevem relações rígidas. Os cinzentos são inter-relações privadas dentro do módulo, não são importantes. Além disso, a classe dos robôs de comércio pode dirigir-se directamente à API da plataforma, mas a independência da plataforma é reduzida.
A expansão ilimitada do módulo conduz a sérios problemas no futuro. Tem a lógica do Expert Advisor praticamente dispersa em diferentes módulos. Os próprios módulos irão interagir uns com os outros, e não há garantia de que as ligações entre eles não se tornem um emaranhado. Imho, todos os quadrados marcados a verde são elementos de um sistema de comércio. A sua decomposição em diferentes módulos viola um dos principais princípios de programação: o encapsulamento de dados e métodos dentro de uma tarefa.
Desde que todos começaram a publicar os seus próprios esquemas, eu também vou continuar. Desta vez é um esquema ainda mais abstracto:
As setas negras descrevem relações rígidas. Os cinzentos são inter-relações privadas dentro do módulo, não são importantes. Além disso, a classe de robôs comerciais tem o direito de aceder directamente à API da plataforma, mas isto reduz a independência da plataforma.
Do lado do redesenho-aperfeiçoamento, vou pensar no assunto (deixá-lo fermentar).
A falta é mais óbvia - este esquema obviamente carece de GUI (visual monitoring/controlling subsystem). Quero desenvolver um esquema unificado (e conveniente!) de interacção entre o Expert Advisor e o GUI. Até agora, sou espontâneo neste assunto, o que realmente me irrita. Gostaria de atingir o mesmo objectivo (abstracção total dos dados em ambas as direcções). Foi por isso que sugeri a tarefa de interface EA/GUI para a formação, estou interessado nela em termos mercantis, queria obter algumas ideias do público.
Deixar a tarefa. Que tarefas são mais solicitadas na GUI ?
Vá a partir daí. Descreva o que pretende obter, seleccione títulos comuns, faça uma estrutura, depois adicione mais algumas coisas, veja como é fácil mudar a estrutura.
Então compreenderá como deve ser, reescrevendo tudo de novo. Vejo as coisas dessa forma.
OMetaDriver diz bem, e o seu sistema está correcto. Dick_fx acrescentaria também que o "motor de negociação" deveria trabalhar com plataformas 10-20 para utilizar os melhores preços.
Mas utilizar um sistema tão correcto só é conveniente em condições ideais - sem erros de estratégia, sem intervenção do utilizador, sem força maior... E na realidade, isto raramente acontece.
Deixe-me dar um exemplo de dick_fx: 25 estratégias estão a funcionar, agregador (impulsionador do comércio) recolhe-as numa posição líquida e coloca-as no mercado, tudo está bem. De repente, algo corre mal na 17ª estratégia e dá previsões pouco saudáveis - diz-se para abrir a 50% do depósito. O Conselheiro Especialista abre obedientemente.
O que faz um cacifo trivial a la MT4:
Agora passemos à "contabilidade correcta". O que deve o comerciante fazer para corrigir o erro (um comércio com 50% de margem - um erro lógico óbvio)?
A questão é: O que é mais fácil? Obviamente, a variante com MT4.
E o que é mais barato? Obviamente, a opção Netting.
Qual é a conclusão? Fazer um motor de mercado com um GUI da MT4 ;)
E mais uma coisa.
Tudo isto é o raciocínio dos comerciantes "certos", e mesmo dos programadores. Se o fizerem para seu próprio prazer, por conta de um bom depósito, então é a única forma de o fazer.
Se tocarmos na escrita dos peritos, verifica-se que ninguém precisa dela "bem". As multidões de comerciantes-clientes não podem ser alteradas, por isso é preciso escrever "para eles".
A opção "deixar o meu emprego" é aceite! =)
E mais uma coisa.
Tudo isto é o raciocínio dos comerciantes "certos", e mesmo dos programadores. Se o fizerem para seu próprio prazer, por conta de um bom depósito, então é a única forma de o fazer.
Se tocarmos na escrita dos peritos, verifica-se que ninguém precisa dela "bem". As multidões de comerciantes-clientes não podem ser alteradas, por isso é preciso escrever "para eles".
A opção "deixar o meu emprego" é aceite! =)