Regras de estrutura. Aprender a estruturar programas, explorar possibilidades, erros, soluções, etc. - página 7
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
Sugiro que se estabeleçam os padrões básicos de desenho:
1. Funcional
2. modelo de objecto
3. Dirigido por eventos .
...
digitar
4. Componente
--
Em geral, qualquer programa (incluindo aquele que se pretende) pode ser visto de diferentes ângulos. // é compreensível.
Durante a análise inicial de um projecto, tento considerar pelo menos 4 aspectos:
1. Estrutural: Organização física e lógica do código do programa e dos componentes do programa.
2. Funcional (não confundir com a abordagem funcional no desenvolvimento): Que tarefas o programa resolve (que produto produz), qual a sua utilização, que produção deve produzir, etc.
3. Comunicativo: Que tipo de interface de utilizador o programa deve ter, com que programas comunica e como, protocolos de comunicação, etc...
4. Gerencial: Como o software é gerido, que configurações precisam de ser feitas, graus de liberdade, etc.
Todos os aspectos estão inextricavelmente ligados, mas olhar a partir destes ângulos diferentes (+ alguns mais) permite não perder subtilezas importantes e, nas fases iniciais, não bocejar algo importante com consequências de grande alcance... )
...Em geral, qualquer programa (incluindo um programa concebido) pode ser visto de diferentes ângulos. // isto é compreensível...
Estou absolutamente de acordo. É um princípio filosófico geral - estudar um fenómeno a partir de diferentes pontos de vista...
E estou a tentar responder à pergunta "O que deve um programa fazer e o que não deve fazer?" no início do desenvolvimento. A primeira parte da pergunta está dentro do sistema (aqui MTS), a segunda parte não está, está fora.
Imho, é muito importante, independentemente do modelo de desenho, ter uma hierarquia de elementos do modelo. O método dedutivo - "do geral para o particular" - funciona então bem, decompondo o modelo nos seus blocos principais e constituintes.
Para trocar ideias / aprender uns com os outros, proponho-me pegar num problema mais ou menos prático e reestruturá-lo em conjunto.
Por exemplo, pelo menos esboçar a estrutura básica (ou, mais precisamente, as variantes de tais estruturas) para um tal problema:
Existe um Expert Advisor escrito desta forma (por exemplo, para testar uma ideia de negociação). Suponha que a ideia no Strategy Tester (no cliente) mostra resultados promissores. Agora precisamos de reescrever o Expert Advisor para o tornar mais amigável ao desenvolvimento. E, em particular, para o dotar de um painel de controlo gráfico do utilizador.
É desejável ou tornar o painel comutável (para optimização no testador), ou mover toda a realização "não gráfica" da EA para um ficheiro pluggable (.mqh), que pode então ser ligado à interface gráfica sem alterações (para excluir) as diferenças no funcionamento das versões "testador" e "gráfica".
Gostaria de ouvir - ler as considerações sobre a estruturação de um tal projecto. Em particular, sobre a implementação do modelo de controlo orientado por eventos num tal projecto. Suponha que a dupla implementação (testador + painel) é um requisito rigoroso do cliente (ou seja, o projecto deve ser feito de qualquer forma, só se pode escolher o método de implementação).
Vamos tentar a tarefa?
Penso que é óbvio que o painel de controlo do Expert Advisor e o Expert Advisor são dois módulos completamente diferentes num único programa. Por conseguinte, exigem ser separados de tal forma que cada parte seja independente da outra. Significa que se alterar uma parte de um Expert Advisor (por exemplo, alteração na lógica de colocar ordens), não tem de alterar a lógica do painel e vice-versa (alteração na interface do painel - não há necessidade de alterar a lógica do Expert Advisor). A primeira coisa que me vem à mente é a criação de uma interface unificada através da qual o painel e o Expert Advisor podem comunicar. Mas infelizmente, os criadores da MQL5 não consideraram a possibilidade de criar ligações horizontais, e por isso, descrever a interface entre eles através da MQL5 não funcionará. Depois permanece o caminho da integração vertical. Um consultor especializado deve ser herdado de uma classe base, que por sua vez contém métodos e dados suficientes para a interacção com o painel. Isto significa que qualquer EA herdada da classe base também será capaz de exibir e interagir com o painel. A implementação de métodos, responsáveis pela interacção com o painel, não deve ser delegada aos descendentes, mas deve ser feita nos bastidores da classe base, ou seja, a mensagem "Descendente! Se quiser interagir com o painel, deve chamar os meus métodos com parâmetros de sucção e tais" não funciona de todo. Idealmente, qualquer Expert Advisor derivado que herde da classe base deverá simplesmente negociar de uma forma conveniente e as suas acções serão automaticamente exibidas neste painel.
Como organizar uma classe base universal é um tema interessante à parte. Vários anos de prática nesta matéria conduziram-me finalmente ao meu esquema universal. Acabou por ser transparente e universal. Se estiver interessado, posso fornecer-lhe o seu fluxograma de base (ha ha, desenhar fluxogramas é afinal uma actividade muito útil). Mas em qualquer caso, cada um tem o seu próprio caminho, e uma boa solução para um não será uma boa solução para outro.
Se estiver interessado, posso dar-lhe um diagrama esquemático (ha-ha, diagramas de blocos de desenho é afinal uma actividade útil).
A primeira coisa que me vem à mente é criar uma interface unificada através da qual o painel e a EA podem trocar dados. 2.
Infelizmente, os criadores da MQL5 não ofereceram possibilidades de criar ligações horizontais e, portanto, é impossível descrever a interface entre eles utilizando ferramentas MQL5.
1. inequivocamente.
2. E os eventos personalizados? É bastante horizontal e universal.
3. depois permanece o caminho da integração vertical. Um consultor especializado deve ser herdado de uma classe base, que por sua vez contém métodos e dados suficientes para interagir com o painel. Isto significa que qualquer Expert Advisor herdado da classe base também obtém a capacidade de exibir e interagir com o painel. A implementação de métodos, responsáveis pela interacção com o painel, não deve ser delegada aos descendentes, mas deve ser feita nos bastidores da classe base, ou seja, a mensagem "Descendente! Se quiser interagir com o painel, deve chamar os meus métodos com parâmetros de sucção e tais" não funciona de todo. Idealmente, qualquer Expert Advisor derivado herdado de uma classe base deveria simplesmente negociar de uma forma conveniente, enquanto as suas acções seriam automaticamente exibidas nesse painel.
Uma vez que não estou de acordo com o ponto 2, ainda não estou a cavar esta variante.
--
Tenho uma alternativa, que considero muito atractiva (variante com painel "desconectável"). Faça o painel sob a forma de um indicador. Se o seu Consultor Especialista estiver no Teste de Estratégia, ele simplesmente não carrega o painel. O bónus adicional é que o painel funciona num fio diferente, deixando mais recursos para o Conselheiro Especialista.
Quanto à versatilidade do painel, não vejo nenhum obstáculo importante para que o painel seja totalmente configurável através de um ficheiro ini. Por outras palavras, pode prescrever aí absolutamente todos os dados necessários para criar qualquer painel a partir de um conjunto limitado de componentes visuais + códigos de eventos que devem gerar ao interagir com um utilizador.
Como organizar uma classe de comércio de base universal é um tópico interessante à parte. Vários anos de prática sobre este assunto levaram-me finalmente ao meu esquema universal. Acabou por ser transparente e universal. Se estiver interessado, posso mostrar-lhe o seu diagrama de blocos básico.....
1. inequivocamente.
Nahr Porquê? A super-universalização é tão má como a optimização prematura.
E blocos de ligação de um módulo através de eventos... é lento e inconveniente.
Vá lá. Na verdade estou bastante interessado, e poderia ser útil na prática.
A moldura azul é as entidades de classe de base. A moldura vermelha são as entidades da classe derivada. Pode-se ver que a classe base impõe a definição da sua lógica sobre o descendente em quatro métodos. Esta é a forma como reduz a descrição de qualquer estratégia a uma descrição de apenas quatro situações:
1. Se todas as regras de abertura de posição longa tiverem sido cumpridas, a posição longa é aberta no método InitBuy()
2. Se todas as regras de fecho de posição longa forem cumpridas - a posição longa é fechada usando o método SupportBuy()
3. se todas as regras para abertura de posição curta forem cumpridas - então a posição curta é aberta usando o método InitSell()
4. Se todas as regras para fechar a posição curta forem cumpridas - então a posição curta é fechada no método SupportSell()
De acordo com esta lógica, a inversão da estratégia é descrita não num método (por exemplo, fechar longo aberto curto), mas em dois métodos que não dependem um do outro. Acontece que esta abordagem é muito conveniente porque nos permite, por exemplo, proibir a venda ou fechar à força posições com um clique depois de algumas condições gerais que podem ser descritas numa classe base serem satisfeitas.
Em alguns casos, uma estratégia tem dados gerais tanto para as vendas como para as compras que devem ser recalculados após a ocorrência de algum evento, por exemplo, a chegada de um novo bar. Nesses casos, é possível que uma estratégia subscreva os seus próprios métodos de processamento dos eventos. Não é possível abrir posições nestes métodos, mas é possível fazer vários cálculos.
Outro ponto interessante é como lidar com posições em aberto. A classe base armazena uma lista separada de posições longas e curtas. Quando ocorre um novo evento (por exemplo, OnTick), a classe começa a listar todas as posições em aberto e oferece para processar cada uma destas posições uma a uma utilizando os métodos SupportBuy SupportSell. Estes métodos só podem fechar a posição que lhes é oferecida pela classe base neste momento. Todas as outras posições são apenas de leitura. Assim, a classe base impõe aos seus descendentes a ideia de que no momento devem concentrar-se apenas numa única posição. Quando testei esta ideia, descobri que a lógica até do mais complexo Expert Advisor é muito mais simples. Além disso, dá apoio automático à noção de cobertura, porque o Expert Advisor mantém informações sobre as suas posições longas e curtas.Assim que começar a traduzir a execução de uma estratégia para limitar as encomendas, receberá muitas perguntas, de alguma forma:
Depois terá de ser implementado um feedback entre o "executor" e o "analisador" e, além disso, os parâmetros deste movimento não ideal deverão de alguma forma ser incorporados no modelo matemático do analisador
MetaDriver: ... Para verificar ideias estratégicas no provador, uma canção - sem problemas com o comércio ...
À medida que se começa a converter completamente a execução na estratégia para limitar as ordens