OOP vs programmazione procedurale - pagina 5

 
Petros Shatakhtsyan:

Ecco un compito semplice (ci vorrebbe molto da scrivere per spiegarlo in dettaglio).

Tutto avviene in OnTick(). Supponiamo di controllare alcune condizioni e di aprire un ordine. La condizione non è importante, supponiamo che sia un massimo o un minimo.

Il robot si trova naturalmente su qualche grafico e riceve le quotazioni di questo simbolo. È chiaro che non abbiamo solo una funzione OnTick, ma anche altre funzioni: OnTrade, OnTimer, funzioni personalizzate, ecc.

Pertanto, tutte le variabili condivise devono essere dichiarate fuori da queste funzioni all'inizio del codice. Per esempio, come il nome del simbolo, la domanda, l'offerta, lo spread, il numero di cifre della quotazione, ecc. Ce ne saranno decine.

Questo robot farà trading su un solo simbolo, cioè dove si trova. Supponiamo che ci siano 20 grafici di questo tipo e che installeremo lo stesso robot su tutti loro per fare trading simultaneamente per tutte le 20 coppie.

Ma questo non è un robot di trading multi-valuta, come alcuni commercianti del mercato hanno sottolineato.


Qui dobbiamo trasformarlo in un robot multicurrency. Cioè lo mettiamo su qualsiasi grafico (solo su 1 grafico) e apre accordi per 20 coppie. Significa che lo lanciamo nel tester in modalità solitaria e farà trading su quelle coppie che sono in Market Watch.

Ecco come lo implementerete senza OOP. Trasformerete tutte le variabili comuni in array di 20 elementi?

E che dire delle funzioni che saranno chiamate simultaneamente per tutte le coppie?

Non si può fare a meno dell'OOP. :)


P.S. Voglio notare che non ho un'educazione russa, ed è per questo che ho scritto a lungo e non ho avuto il tempo di leggere diverse pagine.

Per creare un motore multicurrency, è necessario scrivere inizialmente un motore multicurrency, non riprogettare un robot che è personalizzato per una coppia.

Il metodo per creare un motore multicurrency non richiede l'uso di OOP. Possiamo scrivere un blocco di codice che prenda i tick di tutte le coppie di valute e applichi le stesse funzioni di analisi e piazzamento degli ordini ovunque. Le stesse funzioni d'ordine conterranno variabili i cui valori cambieranno a seconda della coppia. Questi valori saranno modificati dal blocco che riceve i tick.

 
Реter Konow:
Sarebbe auspicabile condurre a un compito concreto. Questa descrizione non è molto chiara. Nella mia pratica, l'algoritmo non cambia quando cambiano i parametri esterni. È reso universale in anticipo per qualsiasi valore di questi parametri. Pertanto, non è del tutto chiaro cosa intendi. Descrivilo con un esempio specifico.

Per esempio, 100 varianti di trailing stop devono essere stipate in un solo Expert Advisor. Quando si programma proceduralmente, si ottiene un casino come questo:

if(Trailing_01_ON){
    Trailing1();
}

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

...

...

if(Trailing_99_ON){ Trailing99(); }

100 frammenti di codice identici. Quando il programma è in esecuzione, di solito include solo un trailing stop. I restanti 99 if consumano solo risorse.

Ora per la variante OOP. Durante l'inizializzazione di Expert Advisor, scaliamo l'array con i puntatori in base al numero di piste, creiamo oggetti solo per le piste incluse. Di conseguenza, il seguente codice funzionerà sempre:

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

Se un trailing stop è abilitato, allora cnt=1, cioè non c'è nulla di inutile.

 
Dmitry Fedoseev:

La domanda più rilevante qui non è "come" ma "perché"? Perché codificare qualcosa che è già implementato nel terminale - basta aprire il numero richiesto di grafici e attribuire un EA ad essi? Inoltre, i parametri devono essere diversi per diversi simboli e timeframes.


Niente è stato implementato nel terminale. In primo luogo, viene aperto un solo grafico invece di 20; in secondo luogo, nel tester non sarà possibile testare molte coppie simultaneamente, considerando tutte le posizioni aperte.

Non ditemi che esiste la modalità "Tutti i simboli selezionati in MarketWatch".

 

Un programmatore che non capisce come viene descritto il concetto di "Oggetto" può essere considerato un programmatore dilettante, e non conosce l'arte della programmazione moderna.

 
Dmitry Fedoseev:

Per esempio, 100 varianti di trailing stop devono essere stipate in un solo Expert Advisor. Quando si programma proceduralmente, si ottiene un casino come questo:

100 frammenti di codice identici. Quando il programma è in esecuzione, di solito include solo un trailing stop. I restanti 99 if consumano solo risorse.

Ora per la variante OOP. Durante l'inizializzazione di Expert Advisor, scaliamo l'array con i puntatori in base al numero di barre di trascinamento, creiamo oggetti solo per le barre di trascinamento abilitate. Di conseguenza, il seguente codice funzionerà sempre:

Se una barra di trascinamento è abilitata, allora cnt=1, cioè non c'è nulla di inutile.

Questo è un approccio molto, molto strano per risolvere il compito con i trailing in generale. Non dovrebbe esserci un compito del genere - 100 tipi diversi di trailing stop e una funzione diversa per ciascuno.

È necessario comprimere questi tipi in una o più formule, facendo una funzione di trailing stop comune. Questo è tutto. Certo, dovrete lavorare con la materia grigia, ma l'OOP non c'entra niente...

 
Реter Konow:

Un approccio molto, molto strano al problema del trailing stop nel suo complesso. Non ci dovrebbero essere 100 tipi diversi di trailing stop e una funzione diversa per ognuno.

Questi tipi devono essere compressi in una o più formule e in una funzione finale comune. Questo è tutto. Certo, dovrete lavorare con la materia grigia, ma non ha niente a che vedere con OOP...


Supponiamo un trailing stop su MA, e ce ne sono decine.

E perché comprimere qualcosa quando si può vivere facilmente?
 
Dmitry Fedoseev:

Supponiamo che ci siano delle trailing MA, e ce ne sono diverse decine.

E perché qualcosa dovrebbe essere compresso quando si può vivere con facilità?


Si scopre che l'essenza del tuo argomento a favore dell'OOP si basa sulla facilitazione di una decisione intrinsecamente ridicola. È un argomento dubbio...


Perché dozzine di funzioni di trascinamento diverse? È difficile per un programmatore OOP serio scriverne uno universale?

 
Реter Konow:


Si scopre che l'essenza del tuo argomento a favore dell'OOP si basa sulla facilitazione di una soluzione intrinsecamente ridicola. Argomento dubbio...

Perché all'improvviso è ridicolo?

Quanto sarebbe ridicolo usare 100 se?

 
Dmitry Fedoseev:

Perché all'improvviso è ridicolo?

Sarebbe ridicolo usare 100 iffos.

Non c'è bisogno di usare 100 iffos. Dovete risolvere il problema in modo più efficiente e fare una sola funzione con aggiustamenti successivi a diversi parametri.
 
Реter Konow:
Non c'è bisogno di usare 100 ifof. È necessario risolvere il compito in modo più efficiente e fare una funzione con unità di trascinamento che si adatta a diversi parametri.

E come farete a far adattare il trailing stop a diversi parametri? Ci saranno ancora alcuni rami dell'algoritmo che con alcune combinazioni di parametri non saranno mai eseguiti.

Motivazione: