Minha abordagem. O núcleo é o motor. - página 138
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
"Expandindo o potencial criativo dos apoiadores do OOP", Vereshchagin, Canvas, Petróleo
Obrigado a todos pelos postos informativos.
Hoje vamos testar a comunicação entre a EA e o motor através de recursos. Acabou de terminá-lo. Deve trabalhar também no testador.
Você está trabalhando com a classe CCanvas. É o único em seu desenvolvimento.
A classe é parte do sistema. Se for UM, não há sistema.
Então por que criar objetos de classe e se referir a suas funções pelas regras do OOP?
Você PRATICAMENTE não precisa de OOP para lidar com UMA classe.
Mas, você usa o OOP para lidar com UMA classe. Você não precisa de OOP, no entanto.
Peter, no OOP, objetos de classe são criados para que você possa trabalhar com muitos objetos que não dependem uns dos outros. Quando se trabalha com CCanvas e se tem um gráfico tudo está bem, o OOP não é realmente necessário aqui. Mas quando você precisa exibir várias parcelas em diferentes áreas, é difícil prescindir do OOP e criar múltiplas instâncias de CCanvas.
Ou mais um exemplo. Recentemente me pediram para modificar um consultor especializado em procedimentos para que ele pudesse negociar em símbolos diferentes simultaneamente (rodando em um único gráfico). O estilo de procedimento teria exigido esforços longos e complexos para que o comércio fosse independente 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.
Até você está usando OOP em seu núcleo. Embora você o faça implicitamente:
A fim de não ser infundado, deixe-me finalmente dar um exemplo desse mesmo "núcleo". Mais precisamente, trata-se de um arquivo de inicialização. Há vários núcleos nele.
Deixe-me lembrar que ele é impresso automaticamente, com base no código KIB. Em seguida, colocado no motor. Em seguida, o motor funciona com ele.
Cada núcleo é uma instância de uma classe em termos de OOP. Como você pode chamá-lo, mas é um elemento do OOP. Mas infelizmente, este elemento é feito por si mesmo e inferior em poder conceitual ao que já foi inventado e polido por milhares de mentes não treinadas.
Vocês convenceram Peter dos benefícios do OOP?
Você não vai convencê-lo! Se você tivesse uma memória como a dele, você se perguntaria por que todas essas coisas de OOP são tão complicadas quando você pode fazer tudo tão mais simples? Tornamos todas as variáveis globais, acesso direto de qualquer lugar, sem proibições e restrições - bom!
Isso é para aqueles que em sua mente fraca podem esquecer o que escreveram dez anos atrás - é necessário que o compilador e a linguagem o limitem em todos os sentidos. E quando você se lembra exatamente por que e por que você escreveu esta ou aquela construção em seu código, que tem muitos anos - OOP é apenas a quinta roda no carrinho.
O problema de Peter não está na escolha "OOP ou abordagem procedural", o problema de Peter está no público-alvo. A falta de pessoas que, por um lado, são boas em programação e, por outro lado, preferem trocar de mãos. Eu não observo tais pessoas.
1. Exatamente. Um número limitado de elementos pode ser prescrito no construtor. Portanto, uma tabela dinâmica deve consistir de um número limitado de linhas, mas ao mesmo tempo, ser irrestrita. A solução está apenas na criação de matrizes especiais para parâmetros adicionais e na rolagem de seus valores através das células da tabela.
2. Sim. Constructor cria kernel para motor com base no código que você citou. + imprime os arquivos de conexão. Em seguida, coloco o miolo no motor (DRIVE). Depois disso, o motor pode tocar a GUI desejada. Os arquivos de emparelhamento são conectados à EA e começam a interagir com ela.
Acontece que toda vez que se trata de uma nova manobra, é preciso fazer mudanças no motor (fornecer-lhe o núcleo GUI apropriado). Eu acho que esta é uma solução fundamentalmente errada. Imagine que há centenas de usuários de seu motor. Mas o motor hospedado no mercado ou em outro lugar é apenas um. Como você vai se sair neste caso? Para que cada usuário coloque um motor específico, que ele deve baixar para si mesmo? Como você prepara o núcleo de gui para o motor? Você fornecerá a cada usuário um motor individual? - Isto se tornará rapidamente um pesadelo. Portanto, sua solução não é escalável.
Peter, no OOP, objetos de classe são criados para que você possa trabalhar com vários objetos que não dependem um do outro. Quando você trabalha com o CCanvas e tem um gráfico, tudo está bem, você realmente não precisa de OOP aqui. Mas quando você precisa exibir várias parcelas em diferentes áreas, é difícil prescindir do OOP e criar múltiplas instâncias de CCanvas.
Ou mais um exemplo. Recentemente me pediram para modificar um consultor especializado em procedimentos para que ele pudesse negociar em símbolos diferentes simultaneamente (rodando em um único gráfico). O estilo de procedimento teria exigido esforços longos e complexos para que o comércio fosse independente 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.
Até você está usando OOP em seu núcleo. Embora você o faça implicitamente:
Cada um de seus grãos é uma instância de uma classe em termos de OOP. E o que quer que você lhe chame, é um elemento do OOP. Mas infelizmente, este elemento é feito por conta própria e cede em seu poder conceitual ao que já foi inventado e polido por milhares de mentes não experimentadas.
Vasily, eu entendo porque as funções de desenho são transformadas em uma classe. Porque há outros conjuntos de funções além deles.
Mas minha pergunta foi um pouco diferente. Por que, exatamente, Nikolai utilizaria chamar as funções de desenho através de uma classe, se ele não utilizasse nenhuma outra classe. Ele só desenha.
O objetivo da pergunta era exatamente isso.
Salientei a inutilidade desta ação em termos de lógica, e que ele não está consciente disso.
Também enfatizei que o uso do OOP é muitas vezes irrazoável pelo tamanho das tarefas a serem resolvidas. Afinal de contas, o OOP requer uma classificação de ramificação, e se não existe tal classificação, vale a pena criá-la de propósito?
A questão é que o desenvolvedor deve ser orientado pelas exigências dos mecanismos e não pelas ferramentas.
Peter, no OOP, objetos de classe são criados para que você possa trabalhar com vários objetos que não dependem um do outro. Quando você trabalha com o CCanvas e tem um gráfico, tudo está bem, você realmente não precisa de OOP aqui. Mas quando você precisa exibir várias parcelas em diferentes áreas, é difícil prescindir do OOP e criar múltiplas instâncias de CCanvas.
Ou mais um exemplo. Recentemente me pediram para modificar um consultor especializado em procedimentos para que ele pudesse negociar em símbolos diferentes simultaneamente (rodando em um único gráfico). O estilo de procedimento teria exigido esforços longos e complexos para que o comércio fosse independente 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.
Até você está usando OOP em seu núcleo. Embora você o faça implicitamente:
Cada um de seus grãos é uma instância de uma classe em termos de OOP. E o que quer que você lhe chame, é um elemento do OOP. Mas infelizmente, este elemento é feito por conta própria e cede em seu poder conceitual ao que já foi inventado e polido por milhares de mentes incompetentes.
Você está perdendo seu tempo. Em primeiro lugar, seu exemplo com conselheiro de Perth é um emplastro - ele não pode escrever especialistas, não entende o que está lá e qual é o objetivo, e não pode entender seu exemplo muito claro - você verá, ele, batendo seus olhos, lhe dirá a mesma coisa que disse a Nikolay. Em segundo lugar, você lhe dará uma desculpa para empurrar seu nariz ainda mais alto, dizendo que ele fez um código super único em seu balde sozinho, sem a ajuda de milhares de mentes anteriores, com uma solução excelente melhor do que qualquer solução anterior. Você verá - é exatamente assim que ele posicionará seu balde único com barras deslizantes...
ZS. Eu posso ter falado duramente, mas tenho muito pouca tolerância a estupidez impenetrável.
Cada um de seus grãos é uma instância de uma classe em termos de OOP. E não importa como você o chame, é um elemento OOP. Mas infelizmente, este elemento é feito por conta própria e cede em seu poder conceitual ao que já foi inventado e polido por milhares de mentes incompetentes.
Assim é. Mas ainda assim, existe uma diferença significativa. Quanto a mim, na Peter's - neste exemplar de classe - quase tudo está disponível. E isto não se enquadra no paradigma de encapsulamento do OOP. Além disso, existem variáveis globais.
Portanto, aqui - apenas "elementos do OOP".
Mas, tenho medo, as pessoas não vão gostar do inverso - tenho certeza, Vasily, que quando eu lançar meu projeto OOP, ao contrário, as pessoas vão gritar que "você não pode fazer nada com esta interface, exceto para o que ela é destinada" :)
Acontece que toda vez que você faz uma nova manobra, você tem que fazer mudanças no motor (equipá-lo com o núcleo GUI apropriado). Eu acho que esta é uma solução fundamentalmente errada. Imagine que há centenas de usuários de seu motor. Mas o motor hospedado no mercado ou em outro lugar é apenas um. Como você vai se sair neste caso? Para que cada usuário coloque um motor específico, que ele deve baixar para si mesmo? Como você prepara o núcleo de gui para o motor? Você fornecerá a cada usuário um motor individual? - Isto se tornará rapidamente um pesadelo. Portanto, sua solução não é escalável.
Não, Vasily, você tende a dramatizar tudo).
Há um botão no designer, 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.
Peter, você realmente entendeu mal algo sobre a aplicação do OOP.
É uma forma especial de consciência, não a impeça de evoluir