Programação OOP vs procedimento - página 37

Novo comentário
 
Andrei:

Uma classe tem apenas variáveis internas e nenhuma variável de entrada ou saída. Onde você já viu o uso na programação de tal objeto que não tem contato com o mundo exterior e ferve em seu próprio suco?


+100

 

A discussão me lembra de um vídeo que os caras mostraram recentemente :)


 
Andrei:

A classe tem apenas variáveis internas e nenhuma entrada e saída. Onde você já viu o uso na programação de tal objeto, que não tem contato com o mundo exterior e cozinha em seu próprio suco?

A classe tem uma interface através da qual interage com o mundo exterior. Ele nos permite cortar todas as coisas "desnecessárias" que não são destinadas a blocos externos.

Por exemplo, em meu processador comercial tenho variáveis, algumas das quais são destinadas ao MT4, outras ao MT5 e outras às duas plataformas. Mas todas estas variáveis são absolutamente desnecessárias para qualquer parte do meu TS. Respectivamente, eles não têm acesso a eles. Todas as partes do TS recebem uma interface virtual do processador comercial, na qual apenas as funções necessárias para a operação do TS são definidas, e tudo o que é irrelevante, tudo o que depende da plataforma e "específico do comércio" é removido.

É o mesmo com uma posição comercial - partes do TS não têm acesso direto a uma posição comercial. Eles só podem obter uma interface virtual que permite contar o número de componentes de comércio aberto, e os dados de cada componente. Mas o TS nem sabe com o que está lidando - se é um pedido MT4 ou uma posição MT5. Tudo isso é escondido dela. O TS não deve ter acesso às variáveis utilizadas para lidar com pedidos MT4 ou posições MT5, e não tem acesso a elas.

 
George Merts:

A classe tem uma interface através da qual interage com o mundo exterior. Ele permite cortar tudo "supérfluo" que não se destina a blocos externos.

Aqui, em particular, no meu processador comercial - tenho variáveis, algumas das quais são para MT4, outras para MT5, outras para ambas as plataformas. Mas todas estas variáveis são absolutamente desnecessárias para qualquer parte do meu TS. Respectivamente, eles não têm acesso a eles. Todas as partes do TS recebem uma interface virtual do processador comercial, na qual apenas as funções necessárias para a operação do TS são definidas, e todas as coisas desnecessárias, todas dependentes da plataforma e "específicas do comércio", são removidas.


Vamos ser muito específicos e dar um exemplo muito claro.

1. Cotier na entrada

2. Há um comando de compra/venda na saída.

3. A entrada é convertida em saída pela interseção de dois toalhetes.

O que são os OOPs entre eles e por quê?

 
СанСаныч Фоменко:

Explique isto às metáforas: por que eles escreveram manuais enormes para o terminal, para o idioma e em geral, onde esta montanha de documentação para produtos de software em, por exemplo, Cp... Na verdade, há algum produto de software sem documentação? É estranho que você não veja isso.


Infelizmente, você está misturando as coisas novamente. O manual de um programa não é documentação. Eles costumavam manter a documentação no século passado e obedeciam às normas estatais. Agora não precisamos de tudo isso. Agora temos apenas os ToR. A documentação agora consiste em casos de teste e interfaces de classe. É claro que as aulas são nomeadas de tal forma que só seu nome deixa claro o que ela faz e para que propósito é usada.

 
Ihor Herasko:

Infelizmente, você está mais uma vez confundindo os termos. Um manual de programa não é documentação. No século passado, havia documentação, e eles seguiram GOSTs e assim por diante. Agora tudo isso é desnecessário. Tudo o que resta é o ToR. A documentação agora consiste em casos de teste e interfaces de classe. E, é claro, as aulas são nomeadas de tal forma que poderíamos entender por seus nomes o que elas fazem e para que propósito são usadas.

A documentação foi mantida no século passado, obedecemos a normas estatais e assim por diante. Agora tudo isso é desnecessário.

Concordo plenamente com você aqui, porque eles não escrevem nada sério.

Sempre existiram os ToR. Mas programas tão simples que o algoritmo pode ser completamente definido em TT não foram escritos no século passado e mesmo agora não são escritos por pessoas sérias.

O que se trata de "casos de teste e interfaces de classe" no desenvolvimento de compiladores? Na programação de algoritmos matemáticos?



PS.

Costumava haver uma rubrica para os perls.

Isto está nele.

Um manual de programa não é documentação.

 
СанСаныч Фоменко:

Sejamos específicos e muito claros sobre um exemplo.

1. a entrada é um quociente

2. A saída é um comando de compra/venda.

3. A entrada é convertida em saída pela interseção de dois toalhetes.

O que são os OOPs entre eles e por quê?

É bastante simples.

Há um gerador de entrada. Em seguida, as duas interfaces das varinhas são solicitadas ao Expert Advisor a interface do provedor de dados, a interface das posições comerciais e a interface do processador comercial.

Quando OnTick() é chamado - a mesma função é chamada a partir do gerador de entrada. O gerador de entrada olha para a interface ondulada, compara seu valor passado. Se detecta um crossover, ele olha para a interface de posição comercial. Se ele vê que não estamos em posição - ele chama a interface do processador comercial para a função de compra ou venda. Se ele vê que existe uma posição, se a posição está na direção requerida - não fazemos nada, se é o contrário - chamamos a função de fechamento da posição na interface comercial e compramos ou vendemos.

Você deve observar que o gerador não tem acesso a nenhuma variável, nem para cálculo de toalhetes, nem para obter uma posição comercial, nem para abrir ordens em MT4 ou posições em MT5. O provedor de datas só conhece os toalhetes que foram solicitados. Ele os recalcula a cada tique e os atualiza. Ninguém mais sabe disso. Um processador comercial - cumpre exclusivamente as instruções que lhe chegam através da interface, e não sabe nem mesmo de quem vieram. O Expert Advisor - atualiza a posição comercial em cada tick e a dá à interface solicitada, sem estudar quem precisa dela e o que tem dentro deste bloco. Todos os blocos são separados e se comunicam exclusivamente através de interfaces pré-definidas.

 
СанСаныч Фоменко:

Sejamos específicos e muito claros sobre um exemplo.

1. a entrada é um quociente

2. A saída é um comando de compra/venda.

3. A entrada é convertida em saída pela interseção de dois toalhetes.

O que são os OOPs entre eles e por quê?

/// применение  ООП для элементарных задач (фактически весь код)

OnInit(){

Series FAST_MA=MA(...);

Series SLOW_MA=MA(...);

OnCrossUp(FAST_MA,SLOW_MA,Buy);

OnCrossDn(FAST_MA,SLOW_MA,Sell);

}

Mas é OOP em si mesmo dentro das bibliotecas trabalhadas - é feito para escrever fácil e simples e ao mesmo tempo para fazer tudo debug. Existem interfaces "a fonte das cotações" e "o executor das ordens", "séries cronológicas", "indicadores" e muitas outras coisas... Mas este código curto está pronto para as condições rigorosas do mercado real, com todas as falhas e males

Com um movimento fácil você pode pegar um quociente arbitrário (sintético) ou executá-lo em outro símbolo... ou simplesmente comandar outro Expert Advisor (e esta é a vantagem do OOP, a complexidade interna, e o problema aplicado requer pouco esforço).

 
George Merts:

É bastante simples.

Há um gerador de entrada. Ela - solicita do Expert Advisor a interface do fornecedor de dados, a interface das posições comerciais e a interface do processador comercial. Depois, duas interfaces de vagões são solicitadas do fornecedor de dados.

Quando OnTick() é chamado - a mesma função é chamada a partir do gerador de entrada. O gerador de entrada olha para a interface ondulada, compara seu valor passado. Se detecta um crossover, ele olha para a interface de posição comercial. Se ele vê que não estamos em posição - ele chama a interface do processador comercial para a função de compra ou venda. Se ele vê que existe uma posição, se a posição está na direção requerida - não fazemos nada, se é o contrário - chamamos a função de fechamento da posição na interface comercial e compramos ou vendemos.

Você deve observar que o gerador não tem acesso a nenhuma variável, nem para cálculo de toalhetes, nem para obter uma posição comercial, nem para abrir ordens em MT4 ou posições em MT5. O provedor de datas só conhece os toalhetes que foram solicitados. Ele os recalcula a cada tique e os atualiza. Ninguém mais sabe disso. Um processador comercial - cumpre exclusivamente as instruções que lhe chegam através da interface, e não sabe nem mesmo de quem vieram. O Expert Advisor - atualiza a posição comercial em cada tick e a dá à interface solicitada, sem estudar quem precisa dela e o que tem dentro deste bloco. Todos os blocos são separados e se comunicam somente através de interfaces pré-definidas.


Incrível!

Eu estava me perguntando: existe alguma outra possibilidade na programação moderna de confundir mais abruptamente o problema do nível de ovos?

 
Maxim Kuznetsov:

/// применение  ООП для элементарных задач (фактически весь код)

OnInit(){

Series FAST_MA=MA(...);

Series SLOW_MA=MA(...);

OnCrossUp(FAST_MA,SLOW_MA,Buy);

OnCrossDn(FAST_MA,SLOW_MA,Sell);

}

Mas o próprio OOP está dentro das bibliotecas desenvolvidas - ele é feito para escrever fácil e simplesmente, e tudo é afinado a esse respeito. Há interfaces de "fonte de cotação" e "executor de ordens", "timeseries", "indicadores" e muitas outras coisas... Mas este código curto está pronto para as difíceis condições reais do mercado, com todas as falhas e males

Com um movimento fácil você pode pegar um quociente arbitrário (sintético) ou executá-lo em outro símbolo... ou simplesmente comandar outro Expert Advisor (e esta é a vantagem do OOP, a complexidade interna, e o problema aplicado requer pouco esforço).


MeuOnInit() parece mais ou menos o mesmo - uma dúzia de linhas...

Então?

1...303132333435363738394041424344...48
Novo comentário