Spese generali per l'OLP - pagina 4
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
La mia esperienza dimostra che è necessario.
Ho seguito questa strada circa cinque anni fa, allora su MT4. (Non perché non conoscessi l'OOP, ma perché ero troppo pigro per preoccuparmi delle interfacce e dell'ereditarietà, soprattutto perché a quel tempo MT4 e MT5 erano significativamente diversi in termini di implementazione MQL). Questo mi ha portato alla comprensione della sua fallacia. Questa non è "saggezza", ma una limitazione abbastanza ragionevole, una sorta di "infallibilità". Se vi ricordate sempre di cosa è responsabile ciascuna delle centinaia di variabili, non avete bisogno dell'incapsulamento. Non me lo ricordo, e preferisco avere il minor numero possibile di entità disponibili in ogni blocco di un programma.
Non appena MQL4 è apparso OOP - ho iniziato a tradurre tutti i miei sviluppi in un unico modulo basato su interfacce.
Non sono ancora riuscito a trovare qualcosa di più conveniente del sistema MQL4-order. Se avete un esempio, per favore mostratemelo.
Tutte le API di trading che ho visto sembrano mostruose rispetto a MQL4. Sono anche maldestri.
Non sono mai riuscito a trovare qualcosa di più conveniente di un sistema di ordini MQL4. Se avete un esempio, per favore mostratemelo.
Tutte le API di trading che ho visto sembrano mostruose rispetto a MQL4. E per di più, sono maldestri.
Cosa ne verrà fuori di buono, ogni parametro deve essere disegnato in una funzione separata. Sarebbe più logico ricevere la struttura con tutti i parametri su richiesta, come con i tick.
Non sono mai riuscito a trovare qualcosa di più conveniente di un sistema di ordini MQL4. Se avete un esempio, per favore mostratemelo.
Tutte le API di trading che ho visto sembrano mostruose rispetto a MQL4. E per di più, sono maldestri.
Cosa vuoi dire?
L'essenza stessa degli ordini? Sì, sono d'accordo, è abbastanza pratico.
Ma proprio l'applicazione di OOP a questo sistema, secondo me, è ciò che dà la più grande "vittoria". Diciamo che ho la stessa interfaccia - dà sia la posizione MT4 composta da ordini che la posizione MT5 composta da posizioni MT5, e indipendentemente dalle condizioni di hedging o netting.
Secondo me, è molto più logico e comprensibile quando abbiamo una lista di oggetti ordine (o posizioni MT5) ottenuti tramite la funzione Select() e ci rivolgiamo alle proprietà degli ordini, piuttosto che allo"stato dell'ambiente" (ottenuto tramite la stessa funzione), che ci rivolgiamo tramite funzioni.
La cosa più interessante è se abbiamo bisogno di tracciare diversi ordini contemporaneamente - in questo caso, l'approccio procedurale porta inevitabilmente a uno "pseudo-oggetto" - dobbiamo creare un array di informazioni sugli ordini che devono essere aggiornati quando entriamo in OnTick() e lavorare con i dati degli ordini tramite indici nell'array, proprio come con OOP-pointers agli oggetti ordine.
Inoltre, l'approccio OOP ci darebbe un vantaggio quando si lavora con ordini storici e attivi contemporaneamente, dato che l'interfaccia dell'ordine storico è il successore dell'ordine attivo. E l'approccio procedurale significa che gli ordini storici e attivi sono gestiti da funzioni diverse, il che è molto meno conveniente.
Cosa c'è di buono nel fatto che ogni parametro deve essere tirato da una funzione separata. Sarebbe logico ottenere la struttura con tutti i parametri su richiesta, proprio come con i tick.
Le voci Order.TakeProfit e OrderTakeProfit() sono le stesse. Il primo ha solo la possibilità di memorizzare l'oggetto, e il secondo - la rilevanza. La necessità di conservare è soddisfatta molto raramente, e non in TS. E lì non è un problema creare la struttura.
Io stesso mi sono chiesto perché gli sviluppatori non hanno fatto il ritorno della struttura dell'ordine, e lasciato ogni campo separatamente attraverso una funzione (per la storia è anche un biglietto ogni volta).
In generale, non vedo nulla di veramente sbagliato con MQL4-API (potrebbe funzionare non solo in MT4/5).
Cosa vuoi dire?
L'essenza stessa dei mestieri d'ordine? Sì, sono d'accordo, abbastanza pratico.
Ma proprio l'applicazione di OOP a questo sistema - secondo me - è ciò che dà la più grande "vittoria". Diciamo che ho la stessa interfaccia - dà sia la posizione MT4 composta da ordini che la posizione MT5 composta da posizioni MT5, e indipendentemente dal fatto che sia hedged o netting.
Tu hai il tuo involucro, l'altro ha il suo involucro. La domanda era se è possibile creare un wrapper più conveniente di MQL4.
È molto più logico e comprensibile, secondo me, quando abbiamo una lista di oggetti ordine (o posizioni MT5) ottenuta utilizzando la funzione Select() e ci rivolgiamo alle proprietà dell'ordine piuttosto che allo"stato dell'ambiente" (ottenuto utilizzando la stessa funzione) che ci rivolgiamo attraverso le funzioni.
La cosa più interessante è se abbiamo bisogno di tracciare diversi ordini contemporaneamente - in questo caso, l'approccio procedurale porta inevitabilmente ad un approccio "pseudo-oggetto" - abbiamo bisogno di creare un array di informazioni sugli ordini che devono essere aggiornati quando si entra in OnTick() e gestire i dati degli ordini tramite indici nell'array nello stesso modo in cui gestiamo i puntatori OOP agli oggetti ordine.
Ne ho scritto nel post precedente.
Inoltre, l'approccio OOP ci darebbe un vantaggio quando si lavora con ordini storici e attivi simultaneamente - poiché l'interfaccia dell'ordine storico è erede dell'ordine attivo. La maggior parte delle funzioni sono comuni. E l'approccio procedurale ci permette di gestire gli ordini storici e attivi usando funzioni diverse, il che è molto meno conveniente.
Bene, in MQL4, la storia è gestita dalle stesse funzioni (OrdersHistoryTotal non conta).
Sarebbe bello avere un esempio di codice in cui la propria API commerciale è chiaramente migliore di MQL4-API. Io stesso uso OOP quasi ovunque. E per alcuni compiti specifici faccio dei wrapper commerciali. Tuttavia non sono universali, anche se molto comodi da usare per qualche compito particolare. Tuttavia, voglio ancora confrontare le API di trading universale.
Io stesso mi sono chiesto perché gli sviluppatori non hanno reso il ritorno dell'ordine una struttura, ma hanno lasciato ogni campo individualmente attraverso una funzione (un ticket è anche richiesto ogni volta per la storia).
Alexey Volchanskiy:
Дело в том, что в МТ4 до 600-го билда не было структур )) А новый MQL4 появился где-то в начале 2013 г.
In MT5 c'erano strutture, ma i ritorni attraverso le funzioni ancora.
Forum sul trading, sistemi di trading automatico e test di strategia
Spese generali per OOP
fxsaber, 2017.07.07 08:08
La domanda era diversa, è possibile creare un wrapper più conveniente di MQL4?
In MT5 c'erano delle strutture, ma il ritorno avviene comunque tramite funzioni.
Forse hanno deciso di non rompere la tradizione, ma avrebbero dovuto farlo.
Capisco se i dati sono stati scaricati dal server della società di intermediazione, ma è locale, è preso istantaneamente, potremmo riempire la struttura immediatamente
Probabilmente hanno deciso di non rompere la tradizione, anche se avrebbero dovuto
Capisco se i dati fossero scaricati dal server DC, ma sono locali, vengono presi istantaneamente, si potrebbe riempire la struttura immediatamente
Sì, durante SELECT riempiamo solo un'istanza di una struttura nascosta, i cui campi sono accessibili solo tramite funzioni const (di sola lettura).
Probabilmente, è l'unica decisione discutibile del kernel dell'API commerciale. Per il resto, non so nemmeno di cosa lamentarmi.
Sì, quando SELECT è usato, riempie un'istanza di una struttura nascosta i cui campi sono accessibili solo tramite funzioni const (di sola lettura).