Alguém criou um sistema comercial automatizado de sucesso? Qual é o seu conselho? - página 16

Novo comentário
 
Aleksei Stepanenko #:
Ótimo! E quanto ao lucro com o OOP. Irá logo depois que você aprender?

O OOP lhe dá a capacidade de escrever um código compacto, claro e elegante. Você gasta várias vezes menos tempo escrevendo, modificando e depurando códigos, o que é muito caro. Você pode construir um sistema comercial muito mais sofisticado e experimentar muito mais opções comerciais. É claro, se você não tem nenhuma idéia para um robô rentável - então é melhor não fazer nada. Além disso, não se esqueça da probabilidade de perda direta em caso de erros, cuja probabilidade em bom código OOP é muito menor.

 
Вадим Калашнков #:

O OOP lhe dá a capacidade de escrever um código compacto, claro e elegante.

Não tem.

 
PapaYozh #:

Este não é o caso.

Bem, se você definir uma tarefa para complicá-la deliberadamente, então sim, há mais oportunidades para complicá-la deliberadamente com o OOP.

Mas se você não se tornar como o Macaco com Óculos, você fica muito mais claro, mais estruturado e com código de manutenção com o OOP.

 

Eu não sou contra a OOP, amigos. Gosto de sua idéia de objeto. E eu o utilizo parcialmente, mas na forma de estruturas, ou melhor, de uma série de estruturas. É suficiente no comércio para armazenar todos os dados de um gráfico e não executar loops em cada barra. Mas acho que isso é tudo o que precisamos. Naturalmente, pode-se escrever tudo no OOP, aqueles que estão acostumados a ele. Mas elas estão longe de ser lucrativas como as processuais. Toda a questão está em um sistema lucrativo, se você o tem, você pode escrevê-lo por goto-code :)

O tema do ramo está pairando sobre a forma de resolvê-lo.

 
Aleksei Stepanenko #:

E eu o uso em parte, embora sob a forma de estruturas, ou melhor, de uma série de estruturas.


Em Java tem até seu próprio nome: POJO (Plain Old Java Object)

;)

 
Georgiy Merts #:

O código OOP é visivelmente mais claro, mais estruturado e mais fácil de manter.

Este não é sempre o caso e depende não do OOP, mas da limpeza do código, da nominação.

 
Aleksei Stepanenko #:

Eu não sou contra a OOP, amigos. Gosto de sua idéia de objeto. E eu o utilizo parcialmente, mas na forma de estruturas, ou melhor, de uma série de estruturas. É suficiente no comércio para armazenar todos os dados de um gráfico e não executar loops em cada barra. Mas acho que isso é tudo o que precisamos. Naturalmente, pode-se escrever tudo no OOP, aqueles que estão acostumados a ele. Mas elas estão longe de ser lucrativas como as processuais. Toda a questão está em um sistema lucrativo, se você o tem, você pode escrevê-lo por goto-code :)

O tema do ramo está pairando sobre a forma de resolvê-lo.

O uso de estruturas não é OOP. Todos os benefícios do OOP começam quando você começa a usar os padrões OOP. Herança, singletons, facetas de objetos, classes de interface, etc. Além disso, você não pode passar sem o OOP se tiver mais de 2 pessoas em sua equipe. Por exemplo:

enum Direction
{
  BUY,
  SELL,
  NO_SIGNAL
};

class Signal
{
public:
  Signal() {}
 ~Signal() {}

  virtual Direction check_signal() { return NO_SIGNAL; }
};

Em seguida, ou você mesmo ou dê 3 pessoas para escrever sinais, por exemplo, para 3 indicadores diferentes:

class RSISignal : public Signal
{
public:
  RSISignal() {}
 ~RSISignal() {}

  Direction check_signal() 
  { 
    Direction result;
    // Checking signal with RSI
    return result;
  }
};

O local onde o sinal é usado é suficiente para fazer:

Signal* signal;

switch signal_type
{
  case RSI : signal = new RSI;
  case CCI : signal = new CCI;
  case MA  : signal = new MA;
};

if (signal.check_signal())
.....

Você, como señor, está completamente abstraído das implementações de corpos funcionais. A implementação e qual indicador é utilizado não é importante para você. Basta usar o check_signal e pronto. Neste exemplo, uma função é utilizada. E se há muitas funções em uma classe - você tem que inserir o switch onde quer que a implementação dependa da configuração ou outra escolha. Além disso, se você utiliza um banco de dados ou, digamos, um arquivo de registro em um monte de lugares - você tem que fazer uma variável global e controlar seu estado em todas as etapas (se o arquivo ou banco de dados está aberto, etc.). Caso você use singleton para esta finalidade - você pode ter certeza de que onde quer que você use arquivo de log/objeto de base - sempre haverá uma cópia do objeto onde você poderá reabrir base/arquivo, usar bandeiras de estado, fazer log em buffer para não escrever em disco em todas as saídas, etc. Se você tem mais de 10.000 linhas de código, a funcionalidade se torna um inferno para o desenvolvedor. E em meio ano, quando você tiver esquecido metade de seu código, será um inferno vivo reelaborá-lo. Além disso, um bom projeto OOP permite adicionar novas funcionalidades ou editar a antiga sem medo de que tudo vá para o inferno se você mudar alguma coisa em algum lugar.

 
Valeriy Yastremskiy #:
Qual é a diferença no OOP em 5 e 4? Século das Luzes. A diferença no ambiente de estoque é óbvia. Bem, as barras são numeradas a partir do final. Não vejo nenhuma outra diferença óbvia no idioma.

Como mínimo, um monte de funções telescópicas foram finalmente eliminadas e, mais importante ainda, uma biblioteca padrão com um grande número de classes úteis foi adicionada.

 
O conhecimento do OOP de alguma forma me aproximará do meu sonho de ganhar 200 libras em 100?
 
Вадим Калашнков #:

Como mínimo, finalmente se livrou de um monte de funções telescópicas e o mais importante, uma biblioteca padrão com um grande número de classes úteis foi adicionada.

especialmente Object.mqh

diretamente dos livros que você, por sorte, cita...padrão brilhante :-)

O tópico não é sobre como você dominou bem o curso OOP e aprendeu a defendê-lo... na minha opinião, é um domínio de merda

De qualquer forma, pegue seus livros didáticos e vá para a escola amanhã.

1...91011121314151617181920212223...42
Novo comentário
Razão: