Cosa può fare il codice OOP che il codice procedurale non può fare? - 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
Vi aspettate davvero che qualcuno di professionale pubblichi una libreria di compex, così come una "prova"? ;) Potrei postarti un link a qualcosa di pronto che non può essere venduto sul mercato qui, ma Alain mi prenderà a calci se lo faccio ;) Puoi visitare il mio profilo e dare un'occhiata alla foto del muro per farti un'idea o mandarmi un pm.
Un'altra piattaforma? Non troverete nessun'altra piattaforma con un compilatore così potente. Assolutamente no.
@James Cater - grazie mille per i tuoi commenti.
Ci sono altre piattaforme là fuori oltre a MT, per quanto riguarda il compilatore più o meno potente non mi interessa davvero, purché io possa scrivere codice semplice.
Quello che vi manca qui è l'educazione, tutti stiamo ancora imparando, alcuni sono solo più avanti sulla strada di altri. Per quanto ne so questo non è un concorso, piuttosto un posto per lo scambio di conoscenze e supporto.
E a proposito, non credo che nessuno in questo forum scriverà un programma da un milione di righe.
Hai mancato il punto Dirk. Le persone non specializzate vogliono esempi di codice semplici e chiari, che in effetti era il mio obiettivo con questo argomento. Ma questo sembra completamente al di là della comprensione degli specialisti.
Le ultime lingue cercano di semplificare le cose per le persone con meno conoscenze di codifica possono essere aggiunte al gruppo dei "codificatori". Il miglior esempio è lo pseudo linguaggio HTML. E questo è il grande errore. Quando MT5 è stato sviluppato molti "neofiti" hanno incolpato lo stile OOP perché era difficile. Ma la verità è che ogni lavoro ha i suoi professionisti. Se vuoi migliorare una piattaforma devi renderla complessa. Più caratteristiche più flessibilità. Lasciare che persone senza conoscenze di codifica provino a farlo è come se qualcuno senza sapere come costruire case ne facesse una. Sarà un disastro.
Circa la lunghezza dei progetti dipende dal codificatore. La mia libreria è di medie dimensioni per il linguaggio MQL. Altri hanno solo bisogno di piccole librerie per creare strumenti. Nel mio caso preferisco spendere tempo nel creare framework per risparmiare tempo e semplificare lo sviluppo in futuro. Se devi fare UI complesse o riutilizzare il codice per altri progetti è il modo più intelligente.
Le ultime lingue cercano di semplificare le cose per le persone con meno conoscenze di codifica possono essere aggiunte al gruppo dei "codificatori". Il miglior esempio è lo pseudo linguaggio HTML. E questo è il grande errore. Quando MT5 è stato sviluppato molti "neofiti" hanno incolpato lo stile OOP perché era difficile. Ma la verità è che ogni lavoro ha i suoi professionisti. Se vuoi migliorare una piattaforma devi renderla complessa. Più caratteristiche più flessibilità. Lasciare che persone senza conoscenze di codifica provino a farlo è come se qualcuno senza sapere come costruire case ne facesse una. Sarà un disastro.
Circa la lunghezza dei progetti dipende dal codificatore. La mia libreria è di medie dimensioni per il linguaggio MQL. Altri hanno solo bisogno di piccole librerie per creare strumenti. Nel mio caso preferisco spendere tempo nella creazione di framework per risparmiare tempo e semplificare lo sviluppo in futuro. Se devi fare UI complesse o riutilizzare il codice per altri progetti è il modo più intelligente.
Quindi la gente non può acquisire conoscenze?
Procedurale vs OOP è un dibattito inutile, 3 anni fa è già stato discusso e la mia risposta è completamente valida, non è stato detto altro qui:
Forum sul trading, sistemi di trading automatico e test di strategie di trading
Programmatori: Quale è la vostra preferenza: OOP vs Procedural
Alain Verleyen, 2013.06.11 13:11
Nel tuo sondaggio manca un'opzione per quelli che non preferiscono nulla. Voglio dire, questa non è solo una questione di preferenze, che non ha senso usare OOP per un piccolo script o anche un semplice EA. OOP aggiunge sempre lavoro ed è vantaggioso solo per progetti complessi e riutilizzabilità del codice (stesso codice usato in diversi progetti). Complesso non è lo stesso che grande, se qualcuno ha un grande progetto ma relativamente semplice non significa automaticamente che deve usare OOP.
Si può vedere il grande potenziale di OOP con MQL5 Wizard sviluppato da Metaquotes, sarebbe molto difficile sviluppare un tale strumento con la programmazione procedurale,anche se è fattibile.
OOP dovrebbe essere usato:
D'ora in poi non accetterò nessun post che non sia concreto, senza un esempio di codice che dimostri perché e come l'OOP dovrebbe essere usato meglio nei casi di cui sopra.
Procedural vs OOP è un dibattito inutile, 3 anni fa è già stato discusso e la mia risposta è completamente valida, non è stato detto altro qui:
OOP dovrebbe essere usato:
D'ora in poi non accetterò nessun post che non sia concreto, senza un esempio di codice che dimostri perché e come OOP dovrebbe essere usato meglio nei casi di cui sopra.
Ho letto tutto questo argomento, e lo trovo interessante, ma il codice macchina non è procedurale? Quindi i linguaggi di alto livello, e OOP incluso, tutti alla fine vengono tradotti in procedurale nel compilatore, giusto? Se tutti i linguaggi sono tradotti in codice macchina procedurale, allora possiamo dire che tutto può essere fatto in procedurale, se il programmatore ha le competenze, per favore qualcuno mi corregga se sbaglio
Tutto può essere fatto in procedurale teoricamente. Non è pratico.
Un mattone è costruito da migliaia di migliaia di particelle di sabbia, quindi si può costruire una casa senza mattoni, solo con la sabbia.
Ma nessuno ci prova nemmeno quando si hanno i mattoni.
Un aereo è costruito con parti già pronte - ali, ruote, sedili, computer, ecc. Alla fine sono tutti fatti di metallo o di plastica o di vetro. Ma nessuno costruirà un aereo di puro vetro, plastica e metallo.
Per il dibattito in generale (in risposta ad Alain e agli altri): Prendete il CArrayObj - un array di oggetti. Questo da solo è sufficiente per rispondere a quello che è il potere di OO (che è molto più di questo). Può memorizzare un array di qualsiasi oggetto - come gli indicatori per esempio.
E senza alcuno sforzo, fare cose complesse per tutti questi diversi indicatori. E se ora volete un nuovo potere a questo, per esempio volete sapere quando un indicatore buffer è attraversato, dovete solo mettere il metodo in CIndicator, tutto qui. E così via. Come lo faresti in procedurale?
E questo può essere fatto in tutti gli aspetti - strategie, trade, operazioni, segnali - qualsiasi cosa.
Tutto può essere fatto in procedurale teoricamente. Non è pratico.
Un mattone è costruito da migliaia di migliaia di particelle di sabbia, quindi si può costruire una casa senza mattoni, solo con la sabbia.
Ma nessuno ci prova nemmeno quando si hanno i mattoni.
Un aereo è costruito con parti già pronte - ali, ruote, sedili, computer, ecc. Alla fine sono tutti fatti di metallo o di plastica o di vetro. Ma nessuno costruirà un aereo di puro vetro, plastica e metallo.
Per il dibattito in generale (in risposta ad Alain e agli altri): Prendete il CArrayObj - un array di oggetti. Questo da solo è sufficiente per rispondere a quello che è il potere di OO (che è molto più di questo). Può memorizzare un array di qualsiasi oggetto - come gli indicatori per esempio.
E senza alcuno sforzo, fare cose complesse per tutti questi diversi indicatori. E se ora volete un nuovo potere a questo, per esempio volete sapere quando un indicatore buffer è attraversato, dovete solo mettere il metodo in CIndicator, tutto qui. E così via. Come lo faresti in procedurale?
E questo può essere fatto in tutti gli aspetti - strategie, trade, operazioni, segnali - qualsiasi cosa.
Questo argomento era intenzionalmente provocatorio, tuttavia la risposta alla domanda principale (cosa può fare l'OOP che il codice procedurale non può fare) è NULLA.
L'OOP non è certamente l'unico modo di costruire e usare i mattoni. Ci sono almeno altrettanti modi per creare cattivo codice in OOP che nel codice procedurale (e molto probabilmente più modi). Basta guardare la "libreria standard" fornita da Metaquotes, che in realtà è tutt'altro che "standard".
OOP contro procedurale è un dibattito inutile e senza fine. Uno più utile dovrebbe essere "Come produrre codice di qualità? Con e senza OOP, con e senza procedurale, con e senza qualsiasi paradigma di programmazione". Se il tuo bisogno è quello di costruire una casa di legno, non hai bisogno di mattoni, ma hai bisogno che sia una buona casa, solida e affidabile.
Tutto può essere fatto in procedurale teoricamente. Non è pratico.
Un mattone è costruito da migliaia di migliaia di particelle di sabbia, quindi si può costruire una casa senza mattoni, solo con la sabbia.
Ma nessuno ci prova nemmeno quando si hanno i mattoni.
Un aereo è costruito con parti già pronte - ali, ruote, sedili, computer, ecc. Alla fine sono tutti fatti di metallo o di plastica o di vetro. Ma nessuno costruirà un aereo di puro vetro, plastica e metallo.
Per il dibattito in generale (in risposta ad Alain e agli altri): Prendete il CArrayObj - un array di oggetti. Questo da solo è sufficiente per rispondere a quello che è il potere di OO (che è molto più di questo). Può memorizzare un array di qualsiasi oggetto - come gli indicatori per esempio.
E senza alcuno sforzo, fare cose complesse per tutti questi diversi indicatori. E se ora volete un nuovo potere a questo, per esempio volete sapere quando un indicatore buffer è attraversato, dovete solo mettere il metodo in CIndicator, tutto qui. E così via. Come lo faresti in procedurale?
E questo può essere fatto in tutti gli aspetti - strategie, trade, operazioni, segnali - qualsiasi cosa.
Nel tuo esempio, quando codifichi OO e clicchi su compila, verrà generato del codice macchina. Ma questo codice macchina è procedurale o no? Non conosco davvero la risposta, qualcuno qui lo sa? Se il codice macchina è procedurale, allora si può chiamare OO solo un linguaggio di livello superiore, che rende più facile solo il codice, ma niente di speciale, quindi un abile programmatore C può fare lo stesso lavoro che un programmatore OO, infatti, può essere ancora meglio ottimizzato. Quindi la mia domanda è: il codice ex è prodedurale o no?