Minha abordagem. O núcleo é o motor. - página 16
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
No momento, eu tenho um cliente. Eu concluo suas tarefas muito rapidamente. 3-4 horas e uma nova janela totalmente funcional está pronta. Juntamente com a interface de conexão. Também corrijo rapidamente bugs no motor e lhe envio novas versões. 9 janelas em poucos dias + mudanças de motor, correção de bugs, adição de recursos... Tudo muito rápido.
Você deve ter muito tempo livre.
Você entende que só você não é suficiente. A massividade de seu motor dependerá de outros programadores gostarem dele (só você não é suficiente para todos os clientes). E se os progerms não gostarem, então... infelizmente e ah, o destino de sua criação será glorioso.
Os programadores não terão que entrar no código do motor. Eles terão a interface de conexão com ele no arquivo. Já o testei. Tudo funciona.
No momento, eu tenho um cliente. Eu concluo suas tarefas muito rapidamente. 3-4 horas e uma nova janela totalmente funcional está pronta. Juntamente com a interface de conexão. Também corrijo rapidamente bugs no motor e lhe envio novas versões. 9 janelas em poucos dias + mudanças de motor, correção de bugs, adição de recursos... Tudo muito rápido.
Diz bem? 3-4 horas para criar uma janela? Não minutos?
Na verdade, já faz mais de um ano que o faço. E eu não fico confuso)).
Para comparação, implemente a mesma coisa usando o OOP. Talvez você goste. :)
Diz bem? 3-4 horas para criar uma janela? Não minutos?
Não. Você pode fazer isso em minutos se copiar o código de outra janela e fazer alterações. Mas eu estava falando em criá-lo do zero, com pensar em gráficos e trabalhar com estilo.
A propósito, Peter, não se esqueça de adicionar todo tipo de gráficos, como indicadores, somente em janelas, com suporte para alguns formatos de dados (OHLC, como Zigzag, etc.). Espero que tudo isso seja facilmente implementável em seu projeto.
Vou tentar.
Vou tentar.
Eu não vou tentar, eu vou). Aumenta a utilidade de sua criação.
Diz bem? 3-4 horas para criar uma janela? e não minutos?
Que bobagem... fazer 3 janelas em MQL mesmo usando bibliotecas do conjunto de ferramentas padrão MT leva 10 minutos e outros 20-30 minutos para caber altura e XY de botões, edições, etiquetas...
Posso ver duas possibilidades porque o trabalho de Petr pode ser útil:
- criação de uma aplicação separada para gerar código fonte MQL, ou seja, construtor de GUI e não entrar em detalhes de como ele funciona, por assim dizer Visual MQL++ ))))
- Ou: há pessoas que criam suas próprias dificuldades e depois as superam com sucesso © Wingston Churchill
Parece-me que todos os componentes do OOP de Peter estão constantemente agarrados aos detalhes.
E o cerne da questão é precisamente a filosofia e a arquitetura do sistema.
Foi dito acima, com razão, quais são as questões controversas, que parecem ser vantagens para Pedro e desvantagens para seus oponentes:
- monte de variáveis acessíveis globalmente, sem nenhum encapsulamento.
- falta de controle de tipo
- uma confiança rígida em uma implementação particular de armazenamento de dados.
E Peter disse corretamente que o conceito de OOP (pelo menos em minhas sugestões) é projetado para simplificar, "baseado na conveniência do programador". Encapsulamento, controle de tipo, interfaces - tudo isso é projetado para eliminar a própria possibilidade de erro, confusão, mau uso, tanto quanto possível. É isso mesmo.
O conceito de Peter é o oposto. Todos os dados são acessíveis de qualquer lugar, o usuário de qualquer lugar no código tem controle total sobre todos os objetos do programa e pode percebê-los como quiser sem qualquer tipo de restrição (bem, exceto as restrições do MQL).
Peter diz que este conceito "permite alcançar o máximo desenvolvimento". A usabilidade vem em segundo lugar".
Pessoalmente, como programador, eu já não gosto que a conveniência venha em segundo lugar. Mas você pode sacrificar isto se você realmente conseguir muito mais desenvolvimento. Bem, eu quero ver o que é. Onde a abordagem OOP com restrições e encapsulamento não permite alcançar tal desenvolvimento, como esta abordagem com pleno acesso à enorme variedade de propriedades, jogadas em uma série de tamanhos monstruosos. (Para não mencionar a necessidade de lembrar de tudo isso).
Como corretamente apontado acima, a abordagem faz lembrar o TurboVision da Pascal. Embora, restrições de tipo de controle e encapsulamento já tenham sido implementadas nessa biblioteca.