Meno codice, più azione... scrivere un EA - pagina 2

Nuovo commento
 
Maxim Kuznetsov:

lo stile del caso d'uso è fondamentalmente procedurale, in quanto è il più comune. I potenziali utenti(programmatori principianti) scrivono in questo modo.

Quello che voglio dire è che il suo stile è procedurale nella sua essenza. Cioè, è procedurale sia all'interno che all'esterno, con tutti i problemi che ne derivano. A livello di utente, non si possono rivelare i dettagli dell'implementazione per una questione di principio. E tu hai una cosa molto specifica che accade nel tuo codice a livello dell'utente:

double GetData(EA *ea,int id,int shift,double &data[])
{
#ifdef __MQL4__
   // для 4-ки всё просто - по идентификаторам серии и бара получить данные
   switch ((ENUM_SERIES)id) {
      case FAST_MA:
         return data[shift]=iMA(ea.Symbol,ea.Period,FAST_MA_PERIOD,0,FAST_MA_METHOD,FAST_MA_PRICE,shift);
      case SLOW_MA:
         return data[shift]=iMA(ea.Symbol,ea.Period,SLOW_MA_PERIOD,0,SLOW_MA_METHOD,SLOW_MA_PRICE,shift);
   }
   return EMPTY_VALUE;
#else
   ...
#endif
}

Macro di compilazione condizionale, chiamate di specifiche implementazioni di funzioni MA, ecc. Cioè non OOP, non FP, ma questo tipo di programmazione procedurale opaca. E come ciliegina sulla torta: ea.Symbol, cioè formalmente, è ancora OOP.

 
Maxim Kuznetsov:

Cercherò (o cercherò, se interessato) di fare una base per gli EA.

Il risultato sarà inutile (per la maggior parte delle persone) come tutti quelli menzionati nel thread.

perché cerchi subito di scrivere a modo tuo piuttosto che bene. proprio come gli autori di tutti quelli citati.

 
Vasiliy Sokolov:

Voglio dire che il suo stile è di natura procedurale. Cioè, è procedurale sia internamente che esternamente, con tutti i problemi che ne derivano. A livello dell'utente, i dettagli dell'implementazione non possono essere rivelati per principio. E tu hai una cosa molto specifica che accade nel tuo codice a livello dell'utente:

Macro di compilazione condizionale, chiamate di specifiche implementazioni di funzioni MA, ecc. Cioè non OOP, non FP, ma questo tipo di programmazione procedurale opaca. E come ciliegina sulla torta: ea.Symbol, cioè formalmente è ancora OOP.

Ancora una volta, il caso d'uso è scritto dal presunto punto di vista dei potenziali utenti.

Ma in misura sufficiente per poter procedere alla biblioteca senza toccare il caso d'uso stesso.

Dobbiamo usare la compilazione condizionale, perché sia il 4 che il 5 sono nel forum.


 
Maxim Kuznetsov:

Ancora una volta, il caso d'uso è scritto dalla prospettiva presunta dei potenziali utenti.

Per riformulare: dov'è il requisito di stile procedurale per inserire chiamate di funzioni specifiche dipendenti dalla piattaforma come iMA(...)?

Maxim Kuznetsov:

Ma in un volume sufficiente per permettere di procedere alla biblioteca senza toccare il caso d'uso stesso.

Come possiamo farlo quando il caso d'uso è pieno di chiamate specifiche di funzioni dipendenti dalla piattaforma?

Maxim Kuznetsov:

Devi usare la compilazione condizionale perché ci sono sia il 4 che il 5 nel forum.

Quindi il "codice universale" a livello di caso utente non può nemmeno essere indipendente dalla piattaforma?

 
Maxim Kuznetsov:

...

Se stiamo parlando di user-case - comandamento numero uno: nessuna implementazione specifica a questo livello. Ma a livello di user-case si ha già piena dipendenza da: 1) piattaforma, 2) API del terminale. Cioè l'implementazione proposta è completamente incoerente con il concetto dichiarato.

 
Vasiliy Sokolov:

Se stiamo parlando di user-case - comandamento numero uno: nessuna implementazione specifica a questo livello. A livello di caso utente, si ha già una completa dipendenza da: 1) piattaforma, 2) API del terminale. Cioè l'implementazione suggerita non corrisponde completamente al concetto dichiarato.

In generale, gli sviluppatori scrivono in MQL, e per le API dei terminali di trading MT4, MT5 :-) Pertanto, l'uso del terminale API è normale.

Il caso d'uso dovrebbe dimostrare/fare le cose tipiche della zona. Non solo aggiungere un paio di numeri, ma avere uno scopo comprensibile per l'utente, quello che vogliamo raggiungere. Il minimo scopo possibile degli Expert Advisors è il trading :-) Il più semplice Expert Advisor che posso pensare è quello di fare trading sulle medie di incrocio. È riportato per intero nel post di origine.

A proposito, funziona. In questo momento, invece di scambiare funzioni, si stanno disegnando stub e segni di spunta :-) sto scrivendo/debuggando i dati. Non appena la parte con i dati, anche se grezza, ma pronta per la discussione - la posterò


 
Maxim Kuznetsov:

Generalmente si scrive in MQL e API dei terminali di trading MT4, MT5 :-) quindi riferirsi al terminale API è normale.

Il caso d'uso dovrebbe dimostrare/fare le cose tipiche del settore. Non basta aggiungere un paio di numeri, ma avere un obiettivo comprensibile all'utente, quello che vogliamo raggiungere. Il minimo scopo possibile degli Expert Advisors è il trading :-) Il più semplice Expert Advisor che posso pensare è quello di fare trading sulle medie di incrocio. È riportato per intero nel post di origine

E per come funziona. Al momento sto scrivendo/debuggando dati invece di funzioni di trading e disegnare tick :-). Appena parte con i dati, anche se grezzi, ma saranno pronti per la discussione - lo posterò anche

Lo scrivi correttamente. Ma l'utente capisce molto meglio questo pseudocodice:

if(SMA(Close, 12) > SMA(Close, 24))
   BUY();
else
   SELL();

Un'altra cosa è che farlo funzionare in questa forma (procedurale, noto) è molto difficile, ma è comunque possibile. Questo è ciò che si dovrebbe cercare di ottenere - rendere le istruzioni a livello utente il più semplice e astratto possibile. Ma nel vostro codice, l'utente deve specificare macro di compilazione condizionali, funzioni specifiche per calcolare le medie e altri dettagli tecnici che semplicemente non può gestire.

 
Vasiliy Sokolov:

Per riformulare: dove lo stile procedurale ha l'obbligo di inserire chiamate a funzioni specifiche dipendenti dalla piattaforma come iMA(...)?

Quanto intoccabile, se il caso d'uso è pieno di chiamate di funzioni specifiche dipendenti dalla piattaforma?

Quindi il "codice universale" a livello di caso utente non può nemmeno essere indipendente dalla piattaforma?

4/5 piattaforme hanno diverse API, succede così.

Non sto scrivendo un altro livello di compatibilità per tutto, o una libreria universale. Per quanto non voglia farlo :-)

solo la base per gli EA.

 
Vasiliy Sokolov:

Bene, lo scrivi correttamente. Ma l'utente capisce molto meglio questo pseudocodice:

Un'altra cosa è che è molto più difficile farlo funzionare in questa forma particolare (procedurale, noto), ma è comunque possibile. Questo è ciò che si dovrebbe cercare di ottenere - rendere le istruzioni a livello utente il più semplice e astratto possibile. Ma nel vostro codice, l'utente deve specificare macro di compilazione condizionali, funzioni specifiche per il calcolo delle medie e altri dettagli tecnici che semplicemente non può gestire.

In linea di principio, puoi usare una voce come quella che hai citato dentro GetData OnCrossSignal. Potenzialmente, puoi anche scrivere degli script :-) Ma tutto a suo tempo... La gestione dei dati è costruita come un tavolo elettronico.

 
Maxim Kuznetsov:

4/5 piattaforme hanno API diverse, è così e basta.

Non sto scrivendo un altro strato di compatibilità per tutto, o una libreria universale. Per quanto non voglia farlo :-)

solo la base per gli EA.

Guarda il codice di Artem. Il suo codice ha un'unica API, che è indipendente dalla piattaforma di destinazione. Ecco perché l'argomento che "funziona così" è strano da sentire.

12345678910
Nuovo commento