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
Forse non è un approccio razionale caricare tutti gli ordini aperti con tutti i loro parametri in un array.
Forse, se ho bisogno di due parametri profit e stop loss nel mio codice, è troppo costoso eseguire il ciclo due volte.
Questo è un codice universale e possiamo tagliare le cose inutili per accelerare il processo finale...
Semplificare
Ecco perché non sopporto l'OOP. È impossibile capire qualcosa. Non ci sono commenti. Cosa si deve fare alla fine?
Perché non cominci a impararlo?
Ecco perché odio l'OOP. È impossibile capire qualcosa. Nessun commento. Cosa si deve fare alla fine?
Questo è il punto: non si capisce, ma si ha una struttura di array con tutti gli ordini e facile da chiamare ovunque. E si esegue il ciclo pesante solo una volta...
Perché non cominci a impararlo?
Riempie l'array con i valori della funzione nel ciclo. La domanda è: perché avete bisogno di una shell di classe? Si può fare con una funzione.
Meno chiamate di funzione, più veloce è il codice.
Riempire l'array con i valori della funzione nel ciclo. La domanda è: perché avete bisogno di una shell di classe? Si può fare anche con una funzione.
La struttura è molto conveniente - non c'è bisogno di impilare gli array e ridimensionarli individualmente. Questo esempio non mostra i vantaggi dell'OOP, solo che ognuno lo fa nel modo in cui gli è personalmente comodo.
Questo è il punto: non si capisce, ma si ha una struttura di array con tutti gli ordini e facile da chiamare ovunque. Allo stesso tempo si esegue il ciclo pesante solo una volta...
Signori litiganti, mettiamola così, se non capite OOP, non lo sapete, allora discutiamo non di programmazione procedurale contro OOP, ma di programmazione procedurale con puntatori a funzioni contro programmazione procedurale senza puntatori a funzioni.
No il tuo esempio è molto buono.
Non si tratta di programmazione procedurale.
C'è un criterio molto più importante per la qualità del programma: la chiarezza del codice.
La soluzione che avete dato è terribile: non è affatto chiaro quale funzione viene chiamata in modo significativo. Scriverei un normale interruttore e un commento per ogni chiamata. Questo è il codice giusto.
Dal tuo esempio concludo che l'OOP è una cosa dannosa.
Meno chiamate di funzione, più veloce è il codice.