Qualcuno ha creato un sistema di trading automatico di successo? Qual è il tuo consiglio? - pagina 16

Nuovo commento
 
Aleksei Stepanenko #:
Grande! Che dire del profitto con OOP. Andrà subito dopo averla imparata?

OOP vi dà la possibilità di scrivere codice compatto, chiaro ed elegante. Si spende molte volte meno tempo a scrivere, modificare e fare il debug del codice, che è molto costoso. Puoi costruire un sistema di trading molto più sofisticato e provare molte più opzioni di trading. Naturalmente, se non avete idee per un bot redditizio - allora è meglio non fare proprio nulla. Inoltre, non dimenticate la probabilità di perdita diretta in caso di bug, la cui probabilità nel buon codice OOP è molto minore.

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

OOP vi dà la possibilità di scrivere codice compatto, chiaro ed elegante.

Non è così.

 
PapaYozh #:

Questo non è il caso.

Beh, se si imposta un compito per complicarlo deliberatamente, allora sì, ci sono più opportunità di complicarlo deliberatamente con OOP.

Ma se non si diventa come Monkey with Glasses, si ottiene un codice molto più chiaro, strutturato e mantenibile con OOP.

 

Non sono contro l'OOP, amici. Mi piace l'idea del suo oggetto. E lo uso parzialmente, ma sotto forma di strutture, o meglio di un array di strutture. Nel trading è sufficiente memorizzare tutti i dati di un grafico e non eseguire cicli su ogni barra. Ma credo che questo sia tutto ciò di cui abbiamo bisogno. Naturalmente, si può scrivere tutto in OOP, chi è abituato a farlo. Ma sono tutt'altro che redditizi come quelli procedurali. L'intera questione è nel sistema redditizio, se lo avete, potete scriverlo con il goto-code :)

L'argomento del ramo è in bilico sul modo di risolverlo.

 
Aleksei Stepanenko #:

E lo uso in parte, anche se sotto forma di strutture, o meglio, di una serie di strutture.


In Java ha persino il suo nome: POJO (Plain Old Java Object)

;)

 
Georgiy Merts #:

Il codice OOP è notevolmente più chiaro, più strutturato e più facile da mantenere.

Questo non è sempre il caso e non dipende dall'OOP, ma dalla pulizia del codice, dalla denominazione.

 
Aleksei Stepanenko #:

Non sono contro l'OOP, amici. Mi piace l'idea del suo oggetto. E lo uso parzialmente, ma sotto forma di strutture, o meglio di un array di strutture. Nel trading è sufficiente memorizzare tutti i dati di un grafico e non eseguire cicli su ogni barra. Ma credo che questo sia tutto ciò di cui abbiamo bisogno. Naturalmente, si può scrivere tutto in OOP, chi è abituato a farlo. Ma sono tutt'altro che redditizie come quelle procedurali. L'intera questione è nel sistema redditizio, se lo avete, potete scriverlo con il goto-code :)

L'argomento del ramo è in bilico sul modo di risolverlo.

Usare strutture non è OOP. Tutti i benefici dell'OOP iniziano quando si iniziano ad usare i pattern OOP. Ereditarietà, singleton, sfaccettature di oggetti, classi di interfaccia, ecc. Inoltre, non puoi fare a meno di OOP se hai più di 2 persone nella tua squadra. Per esempio:

enum Direction
{
  BUY,
  SELL,
  NO_SIGNAL
};

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

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

Poi, o voi stessi o date a 3 persone di scrivere segnali, per esempio, per 3 indicatori diversi:

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

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

Il luogo in cui il segnale viene utilizzato è sufficiente per farlo:

Signal* signal;

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

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

Tu, come senatore, sei completamente astratto dalle implementazioni del corpo della funzione. L'implementazione e quale indicatore viene utilizzato non è importante per voi. Basta usare check_signal e questo è tutto. In questo esempio, viene utilizzata una funzione. E se ci sono molte funzioni in una classe - devi inserire switch ovunque l'implementazione dipenda dalla configurazione o da altre scelte. Inoltre, se usate un database o, diciamo, un file di log in un mucchio di posti - dovete fare una variabile globale e controllare il suo stato in tutte le fasi (se il file o il database è aperto, ecc.). Nel caso in cui usiate singleton per questo scopo - potete essere sicuri che ovunque usiate il file di log/oggetto base - ci sarà sempre una copia dell'oggetto dove potete riaprire la base/file, usare i flag di stato, fare log buffered in modo da non scrivere su disco in ogni uscita, ecc. Se avete più di 10.000 linee di codice, la funzionalità diventa un inferno per lo sviluppatore. E tra mezzo anno, quando avrete dimenticato metà del vostro codice, sarà un inferno rielaborarlo. Inoltre, una buona progettazione OOP permette di aggiungere nuove funzionalità o modificare quelle vecchie senza paura che tutto vada a puttane se si cambia qualcosa da qualche parte.

 
Valeriy Yastremskiy #:
Qual è la differenza di OOP in 5 e 4? Illuminazione. La differenza nelle impostazioni dell'ambiente stock è evidente. Beh, le barre sono numerate dalla fine. Non vedo altre differenze evidenti nella lingua.

Come minimo, un mucchio di funzioni del telescopio sono state finalmente eliminate e, cosa più importante, è stata aggiunta una libreria standard con un numero enorme di classi utili.

 
La conoscenza di OOP mi avvicinerà in qualche modo al mio sogno di fare 200 sterline su 100?
 
Вадим Калашнков #:

Come minimo, finalmente ci si è liberati di un mucchio di funzioni del telescopio e, cosa più importante, è stata aggiunta una libreria standard con un numero enorme di classi utili.

specialmente Object.mqh

proprio dai libri che sfortunatamente citi...modello brillante :-)

L'argomento non riguarda quanto bene hai padroneggiato il corso OOP e hai imparato a difenderlo... secondo me è una padronanza di merda

Comunque, prendete i vostri libri di testo e andate a scuola domani.

1...91011121314151617181920212223...42
Nuovo commento