Minha abordagem. O núcleo é o motor. - página 139
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
Vocês todos estão convencendo Peter dos benefícios do OOP?
Você está desperdiçando seu fôlego.
Vocês estão certos, eu sei de tudo isso e entendo muito bem. Mas aparentemente Peter toca um acorde mental de minha OOP-alma com seu "eu não quero, eu não vou", então eu estou constantemente caindo nestas infinitas explicações, discussões e brigas.
E o motor carregará os grãos de um arquivo de texto. Não é difícil de fazer.
Ah, estou vendo. Sim, é melhor assim. Portanto, seu núcleo é um arquivo de texto - essencialmente um grupo de configurações para o motor.
Não, Vasiliy, você tende a dramatizar tudo)).
Há um botão no construtor que, ao ser clicado, imprime todos os arquivos.
E o motor carregará os grãos de um arquivo de texto. Não é difícil de fazer.
Desculpe interromper, mas só queria saber - como o refator deve ser feito ? por exemplo, mudar maus nomes ou geralmente a composição/localização de elementos
Ah, estou vendo. Sim, isso é melhor. Portanto, seu núcleo é um arquivo de texto - essencialmente um grupo de configurações para o motor.
Sim. Exatamente. Todas as informações necessárias para que o motor reproduza uma GUI específica e trabalhe com ela. Agora mesmo estou instalando-o diretamente no motor, e depois o farei carregar a partir do arquivo que o construtor imprime.
Desculpe interromper, mas só queria saber - como o refator deve funcionar ? por exemplo, mudar maus nomes ou a composição/localização de elementos em geral
Tudo isso está no construtor. O código KIB é escrito e o arquivo é recompilado.
Veja como trabalhar com a construtorahttps://www.mql5.com/ru/blogs/post/717782
Ou outro exemplo. Recentemente me pediram para modificar um consultor especializado em procedimentos para que ele pudesse negociar simultaneamente em vários símbolos (rodando em um único gráfico). O estilo de procedimento teria exigido longos e complexos esforços para torná-lo comercializado independentemente em símbolos diferentes ao mesmo tempo. Em contraste, eu simplesmente coloquei todo o código de procedimento em uma classe e criei três exemplos. Especifiquei um conjunto individual de configurações para cada um deles, incluindo o símbolo de trabalho, etc. O código funcionou corretamente na primeira tentativa. O código funcionou como deveria ter funcionado na primeira tentativa. O usuário ficou satisfeito.
Tive um exemplo semelhante esta semana, me pediram para fazer um Expert Advisor que abre a compra na abertura de um bar em uma TF e abre a venda na abertura de um bar em outro).
Mas eu reescrevi uma função trivial para definir uma nova barra em uma classe e criei 2 instâncias da classe para definir uma nova barra. Passei o cronograma do TF como parâmetro durante a inicialização do construtor
5 minutos de trabalho, mas é garantido que tudo vai funcionar e não haverá confusão com os nomes das funções NewBar_TF1() , NewBar_TF2() .... assim como é conveniente inicializar após mudanças de configurações pelo usuário - apagar o objeto no DeInit(), criar o objeto no ONInit()
imho, OOP é conveniente e prático
Tudo isso está no construtor. O código KIB é escrito e o arquivo é recompilado.
Veja como trabalhar com a construtorahttps://www.mql5.com/ru/blogs/post/717782
Sim. Exatamente...
É por isso que há muita confusão com seu motor com outros. Dê nomes não-padronizados aos elementos de seu sistema. Não um kernel - mas um arquivo de configuração autogerado.
Mas ele irá sobrescrever todas as edições dos usuários que estão nos eventos ?
Explique melhor.
É por isso que há muita confusão com seu motor e por que os outros ficam confusos. Dê nomes não-padronizados aos elementos de seu sistema. Não um kernel - mas um arquivo de ajustes autogerados.
Assim, o arquivo, são os núcleos impressos. Há mais de um.