L'OOP sarà richiesto in MQL5? - pagina 2
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
Cosa ti interessa, il processo o il risultato finale?)
Mi interessano entrambi, ma il risultato finale è in qualche modo di più. ("... OOP ti dà molti modi per rallentare i tuoi programmi...")
Non vedo dove OOP mi permetterebbe di scrivere più velocemente che con un approccio procedurale, e questo supererebbe tutti gli svantaggi di OOP. È chiaro chi ne ha bisogno: lo sviluppatore che scrive per altri.
Vi faccio un'analogia: il primo ha preso un coltello e ha intagliato una figura in filigrana, mentre il secondo si è tolto mezzo dito con lo stesso coltello. Qual è lo scopo di tutto questo? Qualsiasi strumento può essere usato per creare sia una "dolcezza" che un barbone totale. Tutto dipende dal programmatore, se è un artigiano o ha una scintilla di talento. Questa è una digressione, ma in sostanza - se preferite il FOP, allora usatelo ulteriormente.
Nel creare il sottogenere, volevo vedere argomenti a favore di OOP in progetti per scopi MT. Forse a causa della mia ignoranza - non sto flirtando - non li ho visti. Non li vedo neanche ora.
Permettetemi di riassumere i vostri post (grazie a tutti, a proposito):
1. Convenienza e velocità di realizzazione del progetto.
2. Manutenzione, aggiornamenti.
3. Il 5 è più veloce perché a chi importa come programmare.
3. Manualità come motivo per un OOP più lento.
------------
(Comprendete che non sono contro l'OOP, volevo solo scoprire da solo cosa può darmi nei compiti per MT - nella creazione di indici, script, Expert Advisors.
OK. C'è un aiuto il 5. Chi può dare un esempio di una semplice indiretta da MT4 standard scritta usando OOP su 5? Sarete in grado di vedere lì. Si possono anche stimare i ritardi a occhio dal testo, dalla leggibilità del programma, ecc.
1. La convenienza e la velocità del progetto.
2. Manutenzione, aggiornamenti.
1. OOP è molto conveniente per coloro che capiscono i principi di base. Lo si può sentire anche nelle applicazioni più semplici. Qualsiasi applicazione è più conveniente da fare con OOP.
2. La dimensione di un progetto non è un ostacolo, purché non sia difficile da capire. E se un programma è orientato agli oggetti, non è molto difficile capirlo. Un esempio è il terminale di SaxoBank. È scritto in C#, che è un linguaggio orientato agli oggetti. Ogni dll contiene circa 20 000 linee di codice. Se non fosse per l'OOP sarebbe quasi impossibile capire una tale quantità di informazioni, tanto più per modernizzarla.
Non hanno più l'OOP nel loro nucleo (anche se l'OOP assoluta è praticamente inutilizzabile). Avremmo dovuto creare classi astratte fin dall'inizio e usare l'ereditarietà e il polimorfismo per raggiungere oggetti reali. Per esempio, per creare una classe base astratta per indicatori personalizzati con metodi e proprietà astratte. È meglio costruire un albero gerarchico di classi: un albero per gli oggetti grafici, per lavorare con l'account, per gli orari e l'accesso alle serie temporali, ecc. E le procedure e le funzioni predefinite dovrebbero essere lasciate solo con le routine elementari che richiedono velocità. Poi si potrebbero espandere le capacità della piattaforma da qualsiasi livello di astrazione, il che ridurrebbe la dimensione del codice, migliorerebbe la sua leggibilità e la facilità di comprensione per altri programmatori. E in MT5 ha già implementato cose abbastanza complesse a livello di procedure (infatti l'intera piattaforma è pronta all'uso) e non ho visto la possibilità di accedere tramite puntatori almeno ai descrittori delle strutture interne create, il che è molto limitante (a giudicare dalla guida). In generale, la necessità di OOP è discutibile, con una tale implementazione potrebbe essere limitata alle strutture e al posizionamento dinamico. L'OOP dovrebbe essere supportata dal basso da un'ampia gerarchia di classi .
Ci vogliono 1-3 anni di programmazione per rendersi conto che i programmi NON SONO SCRITTI, ma LETTI.
Ci vogliono altri 1-2 anni per capire che i programmi non sono scritti per un computer, ma per un umano (in particolare, per se stessi).
Poi ci vogliono 1-2 anni per notare che OOP e C++ contraddicono il modo di pensare umanoide e il metodo di costruire linguaggi umani.
Ci vogliono altri 1-2 anni per studiare il codice degli altri e capire che i programmi migliori e più affidabili sono scritti in Ce classico.
Beh, dopo questo basta leggere l'intervista di Dijkstra sul fatto che C++ e OOP gli fanno venire il mal di stomaco.
E dopo questo (4-9 anni in totale) le domande "sull'OOP" non sorgono affatto, e tali discussioni provocano solo un sorriso indulgente.
E dopo (4-9 anni in totale) non ci sono più domande "su OOP", e tali discussioni evocano solo un sorriso condiscendente.
>> Sono solidale.