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

Novo comentário
 
Petros Shatakhtsyan:

Aqui está uma tarefa simples (seria necessário escrever muito para explicar em detalhes).

Tudo acontece na OnTick(). Suponha, verificamos algumas condições e abrimos um pedido. A condição não é importante, vamos supor, é algum máximo ou mínimo.

O robô fica naturalmente em algum gráfico e recebe citações deste símbolo. É claro que temos não apenas uma função OnTick, mas também outras funções: OnTrade, OnTimer, funções personalizadas, etc.

Portanto, todas as variáveis que são compartilhadas devem ser declaradas fora destas funções no início do código. Por exemplo, como o nome do símbolo, perguntar, licitar, distribuir, o número de dígitos da cotação, etc. Haverá dúzias delas.

Este robô comercializará em apenas um símbolo, ou seja, onde ele se encontra. Suponhamos que existam 20 gráficos deste tipo e instalaremos o mesmo robô em todos eles para comercializar simultaneamente para todos os 20 pares.

Mas este não é um robô comercial de múltiplas moedas, como alguns comerciantes no mercado têm apontado.


Aqui precisamos transformá-lo em um robô com várias moedas. Ou seja, colocamos em qualquer gráfico (apenas em 1 gráfico) e ele abre negócios para 20 pares. Isso significa que o lançamos no modo de teste em modo solitário e ele negociará naqueles pares que estão no Market Watch.

Veja como você vai implementá-lo sem o OOP. Você irá transformar todas as variáveis comuns em conjuntos de 20 elementos?

E quanto às funções que serão chamadas simultaneamente para todos os pares?

Você não pode passar sem o OOP. :)


P.S. Quero notar, que não tenho educação russa, e é por isso que escrevi muito tempo e não tive tempo de ler várias páginas.

Para criar um motor com várias moedas, você deve inicialmente escrever um motor com várias moedas, não redesenhar um robô que seja personalizado para um par.

O método para criar um multi-columidor não requer o uso de OOP. Podemos escrever um bloco de código tirando ticks de todos os pares de moedas e aplicando as mesmas funções de análise e colocação de pedidos em todos os lugares. As próprias funções de ordem conterão variáveis cujos valores mudarão dependendo do par. Estes valores serão alterados pelo bloco que recebe carrapatos.

 
Реter Konow:
Seria desejável levar a uma tarefa concreta. Esta descrição não é muito clara. Em minha prática, o algoritmo não muda quando os parâmetros externos mudam. É tornado universal com antecedência para quaisquer valores destes parâmetros. Portanto, não está muito claro o que você quer dizer. Descreva-o com um exemplo específico.

Por exemplo, 100 variantes de trailing stop precisam ser agrupadas em um único Expert Advisor. Ao programar proceduralmente, você recebe uma bagunça como esta:

if(Trailing_01_ON){
    Trailing1();
}

if(Trailing_02_ON){
    Trailing2();
}
...

...

...

if(Trailing_99_ON){
    Trailing99();
}

100 fragmentos de código idênticos. Quando o programa estiver em execução, apenas uma das paradas de rastreamento será habilitada, e os 99 ifs restantes apenas consumirão recursos.

Agora para a variante OOP. Durante a inicialização do Expert Advisor, escalamos a matriz com apontadores de acordo com o número de barras de fuga, criamos objetos somente para as barras de fuga habilitadas. Como resultado, o seguinte código funcionará o tempo todo:

for(int i=0;i<cnt;i++){
   p[i].Main();
}

Se uma parada móvel estiver habilitada, então cnt=1, ou seja, não há nada desnecessário.

 
Dmitry Fedoseev:

A questão mais relevante aqui não é "como", mas "por quê"? Por que codificar algo que já está implementado no terminal - basta abrir o número necessário de gráficos e atribuir um EA a eles? Além disso, os parâmetros devem ser diferentes para diferentes símbolos e cronogramas.


Nada foi implementado no terminal. Primeiro, apenas um gráfico é aberto em vez de 20; segundo, no testador não será possível testar muitos pares simultaneamente, considerando todas as posições abertas.

Não me diga que há "Todos os símbolos selecionados no modo MarketWatch".

 

Um programador que não entende como o conceito de "Objeto" é descrito pode ser considerado um programador amador, e não conhece a arte da programação moderna.

 
Dmitry Fedoseev:

Por exemplo, 100 variantes de trailing stop precisam ser agrupadas em um único Expert Advisor. Ao programar proceduralmente, você recebe uma bagunça como esta:

100 fragmentos de código idênticos. Quando o programa estiver em execução, ele normalmente incluirá apenas uma parada de trilha. Os 99 ifs restantes apenas consumirão recursos.

Agora para a variante OOP. Durante a inicialização do Expert Advisor, escalamos a matriz com apontadores de acordo com o número de barras de fuga, criamos objetos apenas para as barras de fuga habilitadas. Como resultado, o seguinte código funcionará o tempo todo:

Se uma barra móvel estiver habilitada, então cnt=1, ou seja, não há nada desnecessário.

Esta é uma abordagem muito, muito estranha para resolver a tarefa com trailingings em geral. Não deveria haver tal tarefa - 100 tipos diferentes de paradas de arrasto e uma função diferente para cada uma.

Você precisa comprimir estes tipos em uma ou mais fórmulas, fazendo uma função de parada de trilha comum. Isso é tudo. É claro que você terá que trabalhar com matéria cinzenta, mas o OOP não tem nada a ver com isso...

 
Реter Konow:

Uma abordagem muito, muito estranha para o problema da parada de trilha como um todo. Não deve haver 100 tipos diferentes de trailing stops e uma função diferente para cada um deles.

Estes tipos precisam ser comprimidos em uma ou várias fórmulas, e uma função de rastreamento comum. Isso é tudo. É claro que você terá que trabalhar com matéria cinzenta, mas isso não tem nada a ver com o OOP...


Suponha uma parada na MA, e há dezenas delas.

E por que comprimir algo quando você pode viver facilmente?
 
Dmitry Fedoseev:

Vamos supor que estamos atrás do MA, e há várias dúzias deles.

E por que algo deveria ser comprimido quando você pode viver com facilidade?


Acontece que a essência de seu argumento a favor do OOP se baseia em facilitar uma decisão intrinsecamente ridícula. É um argumento duvidoso...


Por que dezenas de diferentes funções de rastreamento? É difícil para um programador OOP sério escrever um universal?

 
Реter Konow:


Acontece que a essência de seu argumento em favor do OOP se baseia em facilitar uma solução inerentemente ridícula. Argumento duvidoso...

Por que de repente isso é ridículo?

Quão ridículo seria usar 100 ifs?

 
Dmitry Fedoseev:

Por que de repente isso é ridículo?

Seria ridículo usar 100 iffos.

Você não precisa usar 100 iffos. Você precisa resolver o problema de forma mais eficiente e fazer uma função com ajustes de trilha para diferentes parâmetros.
 
Реter Konow:
Você não precisa usar 100 ifofs. Você precisa resolver a tarefa de forma mais eficiente e fazer uma função com trailing que se adapte a diferentes parâmetros.

E como você vai fazer para que a parada móvel se adapte aos diferentes parâmetros? Haverá ainda alguns ramos do algoritmo que, com algumas combinações de parâmetros, nunca serão executados.

123456789101112...48
Novo comentário