PLO - 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
Errore mio - "Non c'è nessun compito che possa essere scritto in OOP e che non possa essere scritto senza OOP".
Cercate di implementare liste, alberi, grafici in MQL4. Questo non è possibile. In MQL5 è facile da fare, non c'è nemmeno bisogno di reinventare la ruota, basta trovare del codice in С++ e usarlo con minimi ritocchi. E naturalmente, i tipi che ho menzionato come esempio sono meglio progettati come classi. Reti neurali, logica fuzzy e molte altre cose possono essere implementate in MQL5 ora. Ma non c'è dubbio che ogni strumento dovrebbe essere adatto al compito da risolvere, e OOP dovrebbe essere usato solo quando necessario. Le grida di coloro che rimproverano le nuove funzioni sono ridicole. Se non vi piace, non usatelo, nessuno vi obbliga ad usarlo. Usare la programmazione funzionale.
Non confondere "impossibile" e "difficile", non c'è nessun compito che non possa essere risolto dalla programmazione procedurale e che allo stesso tempo possa essere risolto da OOP, intendo la funzionalità finale del programma...
E in generale, si può scrivere in linguaggio assembly, ci si può rilassare, serve già pronto :)
OOP si basa sulla stessa programmazione procedurale con l'aggiunta dell'isolamento dei dati e delle funzioni.
Per esempio ci vuole più tempo per scrivere un programma "Hello world!" usando OOP, ma è più veloce per scrivere un grande progetto. Il confine tra la scelta di scrivere OOP o non OOP è molto sfumato e dipende dall'esperienza, dallo scopo e dalle preferenze del programmatore.
Personalmente per me è più conveniente scrivere OOP nella maggior parte dei casi, perché conosco i suoi "colli di bottiglia" e "larghezze" e ho esperienza nella programmazione OOP (C++, JavaScript, PHP).
Ma se scrivo un breve script di test, non uso OOP.
Consiglio: prima di passare all'OOP nei problemi del mondo reale, si dovrebbe fare pratica su esempi semplici, per esempio, scrivere una classe che aggiunga due numeri, ecc.
È improbabile che si possa leggere in un libro su OOP e iniziare a programmare programmi seri in esso senza fare pratica.
Devi abituarti, iniziare a pensare in termini di OOP, vedere cosa devi progettare come classe e cosa no.
Liste, alberi, grafici, non è possibile avere puntatori in MQL4.
Notate che questa è un'implementazione, non un risultato.
Stiamo programmando per il risultato (programma) o per l'attuazione del programma?
Possiamo fare a meno di tutti questi metodi e organizzarlo su array e passaggio di valori.
È complicato, richiede tempo, ma è possibile.
Notate che questa è un'implementazione, non un risultato.
Stiamo programmando per il risultato (programma) o per l'attuazione del programma?
Si può fare a meno di tutti questi metodi e organizzarli su array e passaggio di valori.
È complicato, richiede tempo, ma è possibile.
Quelli "nati" nell'era di Windows e OOP non possono capire DOS e C / Turbo Pascal (per non parlare di Asm)...
IMHO naturalmente, ma....
Quelli che sono "nati" nell'era di Windows e dell'OOP non possono capire cosa sono DOS e C / Turbo Pascal (per non parlare di Asm)...
IMHO naturalmente, ma....
Bisogna provare tutto per cambiare, perché il programmatore può risolvere un problema in più modi contemporaneamente :)
Ma il debug di un programma in Asm è deprimente :)
Notate che questa è l'implementazione, non il risultato.
Stiamo programmando per il risultato (il programma) o per l'implementazione del programma?
È possibile fare a meno di tutti questi metodi e organizzarsi su array e passaggio di valori.
È complicato, richiede tempo, ma è possibile.
Sono d'accordo, si può fare, purché l'array sia dinamico. Ma devi convenire che non è una soluzione molto elegante. È più facile da fare in assembler. Ma OPP è nato prima di Windows. E le sue idee mi hanno aiutato a programmare in linguaggio assembly per MS/CT. E il mio primo libro di testo di programmazione fu il libro in tre volumi di Knuth.
Quindi, a pensarci bene - "OOP è conveniente" :)
E anche: "Se non ti senti a tuo agio nell'usare l'OOP, non usarlo" :)
Due semplici concetti...
OOP è una buona cosa per i grandi programmi.
Se il codice è meno di 50 linee, non hai bisogno di OOP.
Ma quando il codice diventa molto grande, è quasi impossibile capire cosa appartiene a cosa, solo attraverso i commenti.
La probabilità di un errore aumenta quando le variabili non sono condivise come previsto; è un casino.
In OOP, le variabili possono essere memorizzate in un contenitore (classe) insieme ai metodi (funzioni).
Non c'è compito che possa essere scritto in OOP e che non possa essere scritto senza OOP.
È una questione di convenienza))
OOP non è un metodo per risolvere i problemi, ma un modo di strutturare il codice.
È necessario usare OOP se il programma diventa più grande di "Hello word".
In generale, conosco MQL4 da diversi anni e non posso smettere di essere stupito dalla sua miseria. Il quarto MQL è lontano come una stella dalle capacità del C classico. In MQL5 gli sviluppatori hanno deciso di andare avanti. Il numero di funzioni è aumentato e la programmazione è diventata più facile. Il linguaggio è diventato più complesso, sì, ma il prodotto non è stato creato per gli studenti delle scuole.