Discussão do artigo "Biblioteca para criação simples e rápida de programas para MetaTrader (Parte XXVII): trabalho com ordens de negociação - posicionamento de ordens pendentes" - página 4

Novo comentário
 
Artyom Trishkin:

Por que eles os enviam uma vez por segundo? Para inundar o servidor de negociação?

É um intervalo condicional entre as repetições de solicitação. Ele é configurável.
 
Artyom Trishkin:

E preciso de objetos completos para realizar o que planejei. Mas você ainda não está ciente disso e está tentando oferecer maneiras ineficazes de resolver uma pequena parte da tarefa para o trabalho futuro. Mas aqui tudo está interligado, e o conceito geral é o mesmo: as outras coisas planejadas no futuro dependem dessa pequena parte.

De qualquer forma, obrigado por sua opinião - qualquer opinião é útil e faz sentido.

ZЫ. E, sim, não é terrível escrever uma bagunça de código funcional em vez de reescrever constantemente soluções incompletas escritas sem pensar para as próximas tarefas.

Bem, se precisamos deles, precisamos deles. Será interessante descobrir o motivo.

ZЫ. Não seria terrível se ele se livrasse de alterações e redesenhos, mas na verdade isso não acontece. O que é objeto ou não é objeto - mesmo assim, o desenvolvimento do conceito força a reformulação de muitas coisas.

 
Реter Konow:

Bem, se eles são necessários, eles são necessários. Estou curioso para saber para quê.

ZY: Não seria terrível se isso evitasse mudanças e redesenhos, mas na verdade isso não acontece. O que é Objeto ou não Objeto - mesmo assim, o desenvolvimento do conceito força a reformulação de muitas coisas.

Você não está separando os conceitos de "redesenhar" e "estender". Redesenhar é jogar uma coisa pronta no lixo e escrever uma nova a partir do zero. E estender é adicionar novas funcionalidades ao já pronto.

Na maior parte das vezes, aqui isso é apenas adicionado, não reescrito de artigo para artigo.
Mas ao criar algo novo do zero, sim, há muita reescrita. Mas isso é feito nos bastidores dos artigos. As duas únicas exceções são: no início, havia pequenas modificações no que já havia sido publicado para expandir a funcionalidade de todos os componentes da biblioteca e, agora, primeiro testamos a solução em um código simplificado e, em seguida, por meio de um artigo, criamosconsultas de comércio de objetos completas e, depois, criamos uma classe de trabalho com elas.
Agora tudo é feito em um só lugar, na classe de comércio. Mas não deveria estar lá - embora seja comércio, mas não são métodos de comércio - é uma forma de gerenciar métodos de comércio.

 
Artyom Trishkin:

Você não está separando os conceitos de "refazer" e "estender". Redesenhar é jogar fora o produto pronto e escrever um novo do zero. E estender é adicionar novas funcionalidades ao já pronto.

Na maior parte das vezes, aqui isso é apenas adicionado, não reescrito de artigo para artigo.
Mas ao criar algo novo do zero, sim, há muita reescrita. Mas isso é feito nos bastidores dos artigos. As duas únicas exceções são: no início, houve pequenas modificações no que já havia sido publicado para expandir a funcionalidade de todos os componentes da biblioteca e, agora, no início, a solução está sendo testada em um código simplificado e, em seguida, por meio de um artigo, a criação de objetos completos, solicitações de negociação e, depois, a criação de uma classe de trabalho com eles.
Agora tudo é feito em um só lugar - na classe de negociação. Mas não deveria estar lá - embora seja comércio, não são métodos de comércio - é uma forma de gerenciar métodos de comércio.

Eu compartilho tudo perfeitamente bem e sei do que estou falando. E você não está entendendo o que estou dizendo.

Sua preocupação em transformar tudo no mundo em um objeto mostra que você não conhece seus limites conceituais. Não há nenhuma regra na OOP que exija transformar tudo em um objeto, mas você parece não saber disso.

Pense em quanto tempo você gastará lidando com Objetos, cuja necessidade já está sendo prejudicada pela solução concisa e pronta que indiquei. O que mais você pode inventar com isso? Eu não tenho imaginação suficiente. Talvez você tenha. Vá em frente.

 

Quanto à pergunta sobre o que pode ser transformado em um objeto e o que não pode.

1. uma solicitação de negociação é um Objeto.

2. uma solicitação de negociação pendente não é. Por quê? Porque se a transformarmos em um Objeto, ela será uma cópia exata do Objeto de Solicitação de Negociação com uma diferença - seus critérios de repetição e exclusão. Essa diferença é muito pequena para fazer com que uma solicitação de negociação adiada seja "empacotada" a partir de uma solicitação de negociação.

 
Bem, também uma opinião.
 
Entenda a diferença entre nossas abordagens. Por que a solução simples não funciona para você.

Você segue o princípio de "tudo é um objeto". Eu sigo o princípio "tudo é um objeto".

Você cria muitos objetos pequenos e simples, enquanto eu crio um grande e muito complexo. Minhas soluções exigem que você comprima o conteúdo do objeto para que ele se desenvolva, enquanto as suas exigem que você desenvolva cada objeto para que ele ocorra como uma entidade justificada.

A solução que apresentei não requer objetos de consulta diferidos. Seu próximo artigo demonstra a confusão de entidades e suas inter-relações que você criou em torno da simples tarefa de reproduzir solicitações com falha ao servidor.

Tudo o que é necessário é repetir a solicitação do servidor não atendida, mas sua solução cria, surpreendentemente, um mundo inteiro de entidades no qual é possível se perder como em uma selva.

Fico imaginando essa prática de programação e não tenho certeza do que pensar sobre ela. Por um lado, ela é admirável, por outro, é ultrajante. Se eu resolver os problemas dessa forma, não terei vida suficiente para fazer o que quiser. Portanto, não posso fazer uma avaliação inequívoca.

Sei de uma coisa: se você fosse pressionado contra a parede e exigisse uma solução até amanhã à noite, você não criaria nenhum objeto, mas usaria minha solução, que não funcionaria pior.


 
Реter Konow:
...Você cria muitos objetos pequenos e simples, eu crio um grande e muito complexo....

Peter, isso é uma superclasse? Você pode colocar o que não pode colocar? :-) Eles escrevem em livros que isso não é bom.....

Gostaria de salientar ao Artyom que, quando Anatoly escreveu uma série de artigos sobre gráficos, ele forneceu a estrutura de inter-relações entre as classes (leia-se hierarquia). Por exemplo.

Artyom, você fez um ótimo trabalho. Você pode escrever um livro inteiro sobre isso. Em alguns pontos, ele é ainda mais detalhado do que a documentação. E isso é legal. Mas, às vezes, não há ilustrações suficientes no material. Na minha opinião, é claro...

 
Denis Kirichenko:

Peter, o que é isso, super classe? Você pode colocar o que não pode colocar? :-) Os livros dizem que isso não é bom....

Gostaria de salientar ao Artyom que, quando Anatoly escreveu uma série de artigos sobre gráficos, ele forneceu a estrutura de inter-relações entre as classes (leia-se hierarquia). Por exemplo.

Artyom, você fez um ótimo trabalho. Você pode escrever um livro inteiro sobre isso. Em alguns pontos, ele é ainda mais detalhado do que a documentação. E isso é legal. Mas, às vezes, não há ilustrações suficientes no material. Na minha opinião, é claro...

Obrigado.
A estrutura hierárquica ficará para depois - para finalizar. Não quero refazê-la se precisar mudá-la de repente.
 
Denis Kirichenko:

Peter, o que é isso, super classe? Você pode colocar o que não pode colocar? :-) Os livros dizem que isso não é bom....

Tudo acontece e funciona bem. Cada um tem a sua opinião.
Estou lendo artigos e não consigo encontrar o "gerador de entidades" - o princípio pelo qual tudo isso é feito. Estou tentando aprender a pensar dessa maneira e a entender por que penso de forma diferente. E qual é a vantagem de pensar de forma diferente (se houver alguma). Também falei ao Artyom sobre o esquema da biblioteca.


12345
Novo comentário