PLO - pagina 7
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
Secondo me, lei si sbaglia di grosso!
Una volta che avete grandi progetti (almeno diverse migliaia di righe di codice), vedrete che la programmazione con classi (OOP) rende molto facile controllare il processo di sviluppo e, soprattutto, il processo di debug.
Inoltre, OOP rende i progetti più vicini alla vita reale, infatti nella vita reale abbiamo a che fare solo con istanze di oggetti (una casa, un albero, un uomo, una macchina, un ordine, ecc.), cioè con un insieme di proprietà e metodi :)
Provate a fare qualcosa in OOP, vedrete che è più elegante e chiaro. È più facile della programmazione procedurale!
MoneyJinn:
Usa la solita programmazione procedurale in MetaTrader 5.
OOP è uno sviluppo della programmazione procedurale.
Dopo tutto, nessuno contesta che si possa fare a meno delle funzioni. In effetti, è anche più veloce, fino a un certo punto. Non importa che ci siano frammenti di codice che eseguono una stessa azione con dati diversi. È molto facile fare una copia.
L'uso ripetuto di funzioni perde contro l'OOP. L'estensione della funzionalità è sempre la creazione di una nuova funzione e la riprogettazione del codice per rendere possibile la chiamata di questa funzione a seconda delle diverse condizioni. In un programma OOP scritto correttamente, un'estensione è una cosa semplice che non richiede di rifare tutto il codice.
Se mentre si scrivono programmi senza OOP non si ha il disagio di problemi di scalabilità, abbondanza di dati inutili e centinaia di funzioni, sovrapposizione casuale di variabili e necessità di "hot swapping" di funzionalità, non si ha bisogno di OOP.
Sì, non si dovrebbe scrivere in OOP per amore di OOP, non verrà fuori niente di buono. Non dovreste sostituire le funzioni con le classi. Evitare gli anti-pattern
OOP è un bug, come "Niva" o "Lada".
Utilizzare la normale programmazione procedurale in MetaTrader 5.
È accessibile qui come in MetaTrader 4.
Peccato che MetaQuotes non lo sottolinei.
OOP è uno sviluppo della programmazione procedurale.
Se quando si scrivono programmi senza OOP non si hanno problemi di scalabilità, abbondanza di dati extra e centinaia di funzioni, variabili accidentalmente sovrapposte, necessità di "hot swapping" di funzionalità, allora non si ha bisogno di OOP.
Sì, non si dovrebbe scrivere in OOP per amore di OOP, non verrà fuori niente di buono. Non è necessario sostituire le funzioni con le classi.
Sono d'accordo al 100%.
Inoltre, OOP rende i progetti più vicini alla vita reale, perché nella vita reale abbiamo a che fare solo con istanze di oggetti (casa, albero, persona, macchina, ordine, ecc.), cioè con un insieme di proprietà e metodi :)
Cosa è più vicino alla realtà: una casa virtuale, un albero, una persona o vedere il programma nella sequenza in cui viene effettivamente eseguito dal processore?
È una questione religiosa. E ognuno ha la sua scelta.
Il mio post era una risposta alla domanda di un topicstarter bloccato che ha finito per pagare la sua antipatia per l'OOP,
E anche come risposta per i comuni trader che cercano di padroneggiare un prodotto come MT5 o passare a MT5 da MT4.
Il mio post era una risposta alla domanda di un topicstarter bloccato che ha finito per pagare il prezzo della sua antipatia per l'OOP,
Una lista di controllo per il topicstarter:
La programmazione orientata agli oggettiè (leggete la frase al contrario) programmazione orientata agli oggetti. O, programmazione basata sugli oggetti.
Per oggetto intendiamo il codice del programma (di solito isolato da altro codice), che descrive iparametri e il comportamento di oggetti reali (per esempio "macchina") o fittizi (per esempio "grail poopkin"). Ogni oggetto può avere una vita propria e può cuocere nei propri succhi. Un insieme limitato di "canali nervosi" è usato per comunicare con il mondo esterno - come funzioni speciali con accesso esterno.
Secondo me, il vantaggio principale di OOP è che il codice oggetto può essere debuggato indipendentemente da altro codice. E poi si possono assemblare, come un mosaico, oggetti più complessi. Per esempio, un oggetto "donna" potrebbe includere altri oggetti: "fusoliera", "carrello di atterraggio", "serbatoi", "cabina di pilotaggio", ecc.
Il Wizard MQL5 è un buon esempio di MQL OOP. Permette di assemblare l'Expert Advisor da oggetti già pronti. E questi oggetti possono essere combinati.
L'argomento più tragico a favore dell'OOP: coloro che hanno capito la sua essenza, ne rimangono agganciati. È semplicemente più facile da programmare; il codice è più chiaro e strutturato.
...
L'argomento più dannoso a favore dell'OOP: quelli che lo capiscono ne rimangono affascinati. È semplicemente più facile da programmare, il codice è più comprensibile e più strutturato.
È vero, finché non ho imparato l'OOP mi sembrava che fosse una tale schifezza, che non vale nemmeno la pena mescolarla.
Una volta che l'ho capito, tutto è diventato chiaro, non ho più bisogno di inventare nomi unici per le variabili,
Non dovete creare nomi unici per le variabili, non dovete creare nomi unici per i contatori i e j e non dovete cercare in migliaia di volte il codice per trovare dove questa variabile non è nulled. :o), e soprattutto, tutto è proprio davanti ai tuoi occhi - quando apri il programma, tutto è immediatamente chiaro, qui c'è la chiamata dell'oggetto, qui c'è l'interazione degli oggetti, se vuoi capire cosa sta facendo l'oggetto, vai al codice dell'oggetto ...
È vero, finché non ho imparato l'OOP mi sembrava che fosse un tale mucchio di stronzate che non valeva nemmeno la pena di entrarci.
Appena l'ho capito, mi sono liberato di tutto, non ho più bisogno di inventare nomi di variabili unici,
Non dovete creare nomi unici per le variabili, non dovete creare nomi unici per i contatori i e j e non dovete cercare in migliaia di volte il codice per trovare dove questa variabile non è nulled. :o), e soprattutto, tutto è chiaro come il palmo della tua mano, quando apri il programma, tutto è immediatamente comprensibile, ecco la chiamata dell'oggetto, ecco l'interazione degli oggetti, se vuoi capire cosa fa l'oggetto, vai al codice dell'oggetto
+10
Mi opporrei anche all'affermazione che non si dovrebbe usare OOP per piccoli progetti.
Mi sembra che l'OOP dovrebbe essere usato ovunque possibile - il codice si allunga un po', ma la sua trasparenza aumenta molte volte.
+10
Vorrei anche sostenere la tesi che per i piccoli progetti non c'è bisogno di usare OOP.
Mi sembra che l'OOP debba essere spinto ovunque possibile - il codice si allunga in modo insignificante, ma la sua trasparenza aumenta molte volte.
Sono un sostenitore di OOP perché ho capito la comodità di programmare dal basso verso l'alto. Dalle interfacce di interazione degli oggetti all'implementazione delle classi. Tutti quelli che iniziano a implementare le classi non stanno scrivendo in una corretta OOP, stanno scrivendo wrapper funzionali. Tali wrapper non forniscono altro che un comodo spazio dei nomi per variabili e funzioni. Questo è il solito approccio della biblioteca. Ma anche questo minimo va bene ad alcune persone e dicono con orgoglio "Io scrivo in OOP", che però è un loro diritto.
Ci sono programmatori esperti e fondatori di intere correnti nel software moderno che hanno abbastanza esperienza per criticare il paradigma OOP. Questo è un vecchio argomento e, in linea di principio, tutto è stato discusso fino al più piccolo dettaglio molto tempo fa, quando e dove ciò che è perso:
http://blogerator.ru/page/oop_why-objects-have-failed
Ecco la risposta dei sostenitori di OOP
http://bugtraq.ru/library/programming/objectshavenotfailed.html
Confronto della velocità del C++ (piccolo test) Programmazione procedurale e orientata agli oggetti (+ diversi compilatori)
https://www.mql5.com/ru/forum/132434/page3