OOP vs programmazione procedurale - pagina 24
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
1. C'è un criterio. Il criterio principale è la velocità di funzionamento.
La visibilità del codice è il criterio sbagliato.
Tutti passano urgentemente all'asambler..... ma veloce.... è vero che ciò che è veloce è la corretta organizzazione dell'intero progetto o la velocità delle singole funzioni
Tutti si muovono urgentemente per asambiare..... ma velocemente.... ma ciò che è veloce è la corretta organizzazione dell'intero progetto o la velocità delle singole funzioni.
Tutti si muovono urgentemente per asambiare..... ma velocemente.... in realtà ciò che è veloce è la corretta organizzazione dell'intero progetto o la velocità delle singole funzioni
No, continua a codificare attraverso il ***.
Beh, non sono d'accordo.
La chiarezza del codice è una cosa molto importante, perché un codice chiaro è molto più facile da mantenere e modificare.
Proprio così - ho scritto una funzione nuda, e poi l'ho effettivamente "offuscata", resa non visibile e incomprensibile. Questa è stata una decisione forzata. In questo caso, era più importante per me rendere l'intera classe trasparente. Ho sacrificato la chiarezza di una funzione abbastanza banale. Naturalmente, avrei potuto mettere il corpo di questa funzione nel file .mq5, ma credo che le interfacce non dovrebbero essere divise in due file e dovrebbero essere completamente descritte nel file header .mqh.
Anche la velocità è qualcosa da tenere a mente, ma non credo che dovremmo sforzarci per la "velocità ad ogni costo". Ci deve essere una ragionevole sufficienza.
Probabilmente lo stesso punto 3 anche per te
Ho programmato per molto tempo. Dal rilascio di MT3.
Da allora mi sento più a mio agio a scrivere in stile procedurale su mql4. Non ho EA su 1001 linee. Inoltre, ho solo alcune funzioni memorizzate nelle librerie.
E in MQL5 uso la libreria standard. È una cosa conveniente.
Ma l'ottimizzazione delle prestazioni dovrebbe essere fatta per evitare di chiamare funzioni sempre più pesanti. Recentemente, ho modificato un EA da Mql4 a MQL5. Ho usato la libreria presentata qui. Mi ci è voluta mezza giornata per capire tutte le funzioni e ha funzionato, ma l'ottimizzazione era molto lenta. Ho ridotto l'indicatore a 2 barre e tutto ha cominciato a volare.
La conclusione è semplice. Tutti possono scrivere in qualsiasi stile. MQL non è proprio un linguaggio che richiede l'ottimizzazione del codice per guadagnare un paio di millisecondi attraverso la programmazione procedurale. I compiti logici sono più importanti. Il modo in cui sono implementati non ha praticamente alcun effetto sulla velocità.
...
La conclusione è semplice. Tutti possono scrivere in qualsiasi stile. MQL non è proprio un linguaggio che richiede l'ottimizzazione del codice, in modo da poter guadagnare un paio di millisecondi utilizzando la programmazione procedurale. I compiti logici sono più importanti. Il modo in cui sono implementati non ha praticamente alcun effetto sulla velocità.
Quindi, in modo morbido e discreto, lascia intendere che è la programmazione procedurale a fornire alte prestazioni. Da tre giorni vi sto mostrando un problema che può essere risolto solo da OOP senza rallentamenti inutili.
L'OOP ci permette di schermare insiemi di variabili dal resto del codice, il che ci permette di evitare di passare parametri ai metodi quando si eseguono calcoli all'interno di una classe, e questo è un fattore significativo per la velocità. Anche se lo fate in stile procedurale, dovrete creare un numero enorme di variabili globali, e di conseguenza la leggibilità del codice è incredibilmente bassa.
È stato così delicatamente deluso che è la programmazione procedurale a fornire alte prestazioni. Per tre giorni ho mostrato qui un problema che solo OOP può risolvere senza freni inutili.
L'OOP ci permette di schermare insiemi di variabili dal resto del codice, il che ci permette di evitare di passare parametri ai metodi quando si eseguono calcoli all'interno di una classe, e questo è un fattore significativo per la velocità. Anche se lo fate in uno stile procedurale, dovrete creare un numero enorme di variabili globali, e di conseguenza la leggibilità del codice è impossibilmente bassa.
Il guadagno dello stile procedurale è trascurabile, perché il codice viene avviato ad ogni tick in Expert Advisors. E ci possono essere centinaia o anche decine di millisecondi tra un tick e l'altro. Non mi sono mai preoccupato degli indicatori. Non ho trovato alcun profitto reale di indicatori.
Tuttavia, è probabilmente più conveniente usare OOP per grandi progetti. Io stesso preferisco usare le strutture, se devo salvare qualcosa.
L'accesso ai dati è quindi organizzato più chiaramente e il menu a tendina è molto comodo da usare. Se si sostituiscono le strutture con gli array, spesso si fa confusione e il numero di array cresce.
Nel post precedente mettevo l'accento proprio sulla chiamata di funzioni pesanti. Per esempio, una sorta di loop che non ha bisogno di essere chiamato ad ogni tick. E non dovete nemmeno farlo su ogni nuova barra.
È lì che il vero guadagno di prestazioni può essere aumentato.
Sì, è un dibattito divertente: escavatore contro pala.
Immagino che se vuoi piantare un albero, è meglio una pala. Ma se volete scavare una buca, il retroescavatore è probabilmente meglio.
Sì, è un dibattito divertente: escavatore contro pala.
Immagino che se vuoi piantare un albero, è meglio una pala. Ma se vuoi scavare una buca, il retroescavatore è probabilmente meglio.
Sì, è un dibattito divertente: escavatore contro pala.
Immagino che se vuoi piantare un albero, è meglio una pala. Ma se vuoi scavare una buca, il retroescavatore è probabilmente meglio.