OOP vs programmazione procedurale - 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
George Merts:
Ehm... Non ho capito bene il punto.
L'obiettivo era quello di separare il TC dal terminale. Il codice deve essere compilato su entrambe le piattaforme senza alcuna modifica. Il super compito - trasferire tutti i TS scritti a WealhtLab Developer scrivendo solo le classi di lavoro con il server commerciale.
//--------------------------------------------------
Ho chiesto informazioni sul compito attuale per confrontare le sue soluzioni secondo diversi criteri e giungere a una conclusione sull'efficacia di ciascuna. Stai togliendo la conversazione dalla parte pratica. Quando si afferma l'efficacia dell'OOP, bisogna essere in grado di provarla nella pratica. Ma sono pronto a provare la mia opinione.
Allora, qual è il problema attuale? Spero che te lo ricordi)
Se si usano puntatori a funzioni, si può fare a meno della OOP. Ma se non usate i puntatori, dovete capire che non potete raggiungere l'OOP.
Immagino che tu non sia un programmatore? Poi ricorda dove eri 2017.07.05 14:55 GMT 00, con chi stavi parlando e di cosa ))
Se si usano puntatori a funzioni, si può fare a meno della OOP. Ma se non usate i puntatori, dovete capire che non potete raggiungere l'OOP.
No. Finché non c'è un compito concreto che mi mostra che non posso raggiungere l'OOP, non posso afferrarlo. Purtroppo. Queste sono solo parole.
Attualmente ho 4 anni di pratica di programmazione. Potete tranquillamente moltiplicarli per 2, perché sto programmando un sacco di ore ogni giorno. Durante questo periodo, ho risolto innumerevoli compiti diversi. Non ho ancora usato OOP. Non riesco a capire perché ne ho bisogno. Nella mia pratica, tutti i compiti sono risolti senza di esso, e a volte anche in modo più efficiente.
No. Finché non c'è un compito concreto che mi mostra che non posso raggiungere l'OOP, non posso afferrarlo del tutto. Purtroppo. Queste sono solo parole.
Immaginate un ipotetico programma che cambia il suo algoritmo a seconda dei parametri esterni, ci potrebbe essere un numero enorme di varianti. Possiamo risolverlo senza OOP, ma quanto sarebbero stupidi quegli interruttori a più piani. Inoltre, è chiaro che le prestazioni rallenteranno all'aumentare del numero di varianti. È anche chiaro che la costruzione durante l'inizializzazione avviene in OOP e inoltre, durante il funzionamento, non si verifica alcuna ramificazione inutile, cioè l'aumento del numero di varianti non diminuirà le prestazioni.
Una caratteristica distintiva della programmazione strutturata è la divisione dei programmi in blocchi di codice,
che eseguono un compito specifico. In questo caso, i blocchi di costruzione sono funzioni
e moduli (che possono essere spostati in file separati).
Più moderna è la programmazione orientata agli oggetti (OOP).
Il concetto di OOP si riferisce più all'organizzazione dei dati. OOP rende la vita di un programmatore più facile.
I concetti chiave in OOP sono gli oggetti e le classi.
Le classi sono strutture in cui si aggiungono funzioni. E gli oggetti sono variabili strutturate o istanze di classi
La programmazione strutturata è il primo passo. Avendola padroneggiata, il programmatore ottiene un vantaggio. OOP è il passo successivo con il seguente vantaggio
Risolviamo un problema particolare e confrontiamolo.
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 ha importanza, 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 le operazioni 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, e di conseguenza ho scritto a lungo, e non ho avuto il tempo di leggere diverse pagine.
Se si usano puntatori a funzioni, si può fare a meno della OOP. Se non usate i puntatori, dovete rendervi conto che non potete raggiungere l'OOP.
Non sono d'accordo. Una volta scrivevo programmi per la TV digitale, il compilatore era C++, ma veniva usato all'interno del C perché la memoria era scarsa. I puntatori alle funzioni sono stati usati molto estesamente, ma questo non è affatto vicino all'OOP.
...
Ecco come farete senza OOP.
...
La domanda che è più rilevante qui non è "come" ma "perché"? Perché dovresti aver bisogno di codificare qualcosa che è già implementato nel terminale - hai solo bisogno di aprire il numero richiesto di grafici e allegarli all'EA. Inoltre, per diversi simboli e timeframes i parametri sono probabilmente diversi.
Non sono d'accordo. Scrivevo programmi per la TV digitale, il compilatore era C++, ma veniva usato in C perché la memoria era scarsa. I puntatori alle funzioni sono stati usati molto estesamente, ma non è affatto vicino all'OOP.
Non è molto conveniente, ma si può fare con i soli puntatori per quanto riguarda le prestazioni.
E la convenienza è un concetto relativo.
Immaginate un ipotetico programma che cambia il suo algoritmo a seconda dei parametri esterni, ci potrebbe essere un numero enorme di varianti. Possiamo risolverlo senza OOP, ma quanto sarebbero stupidi quegli interruttori a più piani. Inoltre, è chiaro che le prestazioni rallenteranno all'aumentare del numero di varianti. È anche chiaro che con OOP c'è una costruzione all'inizializzazione e poi nessuna ramificazione inutile durante il lavoro; cioè l'aumento del numero di varianti non diminuirà le prestazioni.