Una domanda per gli esperti di OOP. - pagina 11
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
Se un programmatore entra nel mondo del forex, non è necessario essere un professionista e conoscere OOP.
È meglio imparare le complessità del mercato e sviluppare una strategia di trading redditizia. E non importa se si usa OOP o no. La redditività dell'Expert Advisor non ne soffrirà.
Non devi sprecare la tua energia.
George, non si tratta solo di memoria. Ho creato un ambiente di sviluppo confortevole per me, usando la mia lingua madre e anche l'inglese. Il codice bilingue viene ricordato MOLTO meglio di quello monolingue. Soprattutto quando non sei bloccato su parole standard e chiami le variabili con qualsiasi nome tu voglia. Provata. Ho semplicemente ignorato la professionalità nella programmazione e ho iniziato a scrivere a mio piacimento. Di conseguenza, ho iniziato a navigare rapidamente nel mio codice e a leggerlo, ricordarlo e svilupparlo facilmente. Il resto lo sai...
Non credo che possa aiutare. Per me i nomi delle variabili in qualsiasi linguaggio sono cancellati dalla mia memoria quasi istantaneamente, mi alzo da dietro il mio computer e ricordo già solo i principi generali e non posso dire quali variabili sono state inserite in quale posto.
A proposito, questo è il motivo per cui uso sempre coppie di file mqh-mq5 invece di scrivere classi interamente in file mqh - ho bisogno di guardare spesso attraverso i file di intestazione, solo per ricordarmi cosa è disponibile in un caso o nell'altro, ho i file mqh di intestazione necessari aperti in schede e passo a loro, quando ho bisogno di aggiornare nuovamente quelle informazioni. Quando un'intera classe (e ancora di più diverse classi) sono descritte in un file mqh, è più difficile "saltare" attraverso questo file, anche con l'aiuto di schede.
Non posso tenere tutta la struttura nella mia memoria, anche se nella mia gioventù, come ho già detto, ho anche scritto in assembler, ma non ci sono altre opzioni - si hanno solo indirizzi di memoria, e il massimo che la macro assembler permette è creare nomi di aree specifiche usando macro-sostituzioni. Ma mi sono convinto da tempo che in questo modo il numero di errori è molto più grande e il debugging di tale codice è molto più difficile.
Ho già dato un esempio sopra: si verifica un errore e una variabile viene modificata in modo errato per qualche motivo. E la variabile è accessibile da molti posti nel programma. Come prendere un posto dove c'è un errore? Con l'incapsulamento OOP è molto semplice - mettiamo un punto di interruzione nella funzione di interfaccia che modifica la variabile, e appena si verifica una modifica errata - ci fermiamo e immediatamente, tramite la gerarchia delle chiamate, vediamo dove è stata fatta la modifica errata.E con il tuo approccio, Peter, dobbiamo scavare in tutto il codice, cercando in tutti i luoghi in cui si accede a questa variabile, mettendo punti di rottura ovunque, e analizzando tutte le chiamate, non solo quelle errate.
Questo è il punto, può soffrire. Il mio amico ha perso una parte del suo deposito a causa di un errore nel suo codice, mentre OOP rende gli errori meno probabili.
Significa che non è un buon programmatore. Si può essere più confusi nei costrutti OOP complessi che senza.
Le classi devono essere applicate dove è necessario. Ho notato che alcuni programmatori hanno in qualche modo l'ossessione di applicare molte funzioni dove non sono necessarie. Succede lo stesso con le classi.
Invece di scrivere un programma compatto e breve senza OOP, alcuni programmatori iniziano ad applicare classi, molte funzioni e una soluzione semplice si trasforma in un testo chilometrico.
Significa che non è un buon programmatore. Si può essere più confusi nei costrutti OOP complessi che senza.
A parità di condizioni? Ne dubito molto. Se la complessità dei costrutti è la stessa, è molto più facile dargli un senso con OOP.
Tuttavia non annulla la regola "con un cannone su un passero", non ha senso usare grandi complessità OOP dove il compito è molto semplice e compatto.
Anche se, come è già stato detto qui - OOP ci permette di costruire librerie di classi, che sono poi utilizzate in molti progetti.
Diciamo, le stesse classi di array, classi di file... Anche quando si scrive un indicatore molto semplice, senza usare OOP, è molto più facile dichiarare una classe CFile e usare le sue funzioni, piuttosto che usare le funzioni standard per lavorare con i file.Per non parlare della possibilità di sostituire facilmente CFile con altri più specifici, per esempio, ho una classe CLogFile con una capacità di inserire automaticamente il tempo e alcuni dati aggiuntivi nelle stringhe (per i file di log) o la classe CIniFile, che può organizzare i dati in file ini standard, e poi leggerli e usarli quando necessario.
Significa che non è un buon programmatore. Si può essere più confusi nei costrutti OOP complessi che senza.
Le classi devono essere applicate dove è necessario. Ho notato che alcuni programmatori hanno in qualche modo l'ossessione di applicare molte funzioni dove non sono necessarie. Succede lo stesso con le classi.
Invece di scrivere un programma compatto e breve senza OOP, alcuni programmatori iniziano ad applicare classi, molte funzioni e una soluzione semplice si trasforma in un testo chilometrico.
Va bene che il lavoro vero e proprio sia di un centinaio di righe, e il restante paio di migliaia sia una libreria scritta e debuggata molto tempo fa? )))
Se un programmatore usa classi già pronte nel suo programma, come queste: CTrade, CAccountInfo, CPositionInfo, non significa che il suo programma sia basato su OOP.
Dipende se il programmatore crea lui stesso queste classi, o semplicemente le usa senza conoscere gli interni (a livello di testo sorgente) di queste classi.
....
Un esempio è già stato dato sopra - si è verificato un errore, per qualche motivo una variabile è stata modificata in modo errato. E la variabile è accessibile da un sacco di posti nel programma. Come prendere un posto dove l'errore? Con l'incapsulamento OOP è molto semplice - mettiamo un punto di interruzione nella funzione di interfaccia che modifica la variabile, e appena si verifica una modifica errata - ci fermiamo e immediatamente, tramite la gerarchia delle chiamate, vediamo dove è stata fatta la modifica errata.E con il tuo approccio, Peter, dobbiamo scavare in tutto il codice, cercando in tutti i luoghi in cui si verifica il riferimento a questa variabile, mettendo punti di rottura ovunque, e analizzando tutte le chiamate, non solo quelle errate.
Sì, il mio kernel è modificato in tutte le parti del programma e gli errori accadono, ma non ho bisogno di breakpoint. Calcolo nella mia mente e avviso in diversi luoghi per controllare i valori. È così che lo trovo. Sottolineo - conosco molto bene il mio programma.
Ma, sul lato positivo, con queste conoscenze, senza ostacoli sintattici e con una lingua madre, ho enormi opportunità di sviluppo rapido. Ed è per questo che sono contro l'OOP nelle mie soluzioni.
Il frazionamento del codice, la sua monolinguità aliena, la nuova sintassi, le regole aggiuntive - tutto questo rallenterà lo sviluppo del programma. Perderò più fatica e otterrò meno risultati. Lo so per certo.
Se il mio compito fosse quello di costruire e debuggare un programma da pezzi di codice già pronti, solo OOP e librerie andrebbero bene. Agganciare e sviluppare nuove soluzioni sono cose diverse. Molte persone sostengono l'OOP perché vogliono usare pezzi di codice di altre persone e risparmiare sforzo. Io creo le mie soluzioni utilizzando la tecnologia proprietaria e ho diverse esigenze e punti di vista su OOP.
Sì, il mio kernel è modificato in tutte le parti del programma e gli errori accadono, ma non ho bisogno di breakpoint. Calcolo nella mia mente e avviso in diversi luoghi per controllare i valori. È così che lo trovo. Sottolineo - conosco molto bene il mio programma.
Ma il lato positivo è che con tali conoscenze, l'assenza di ostacoli sintattici e la lingua madre, ho enormi opportunità di sviluppo rapido. Ed è per questo che sono contro l'OOP nelle mie soluzioni.
Il frazionamento del codice, la sua monolinguità aliena, la nuova sintassi, le regole aggiuntive - tutto questo rallenterà lo sviluppo del programma. Perderò più fatica e otterrò meno risultati. Lo so per certo.
Se il mio compito fosse quello di costruire e fare il debug di un programma da pezzi di codice già pronti, solo OOP e librerie andrebbero bene. Agganciare e sviluppare nuove soluzioni sono cose diverse. Molte persone sostengono l'OOP perché vogliono usare pezzi di codice di altre persone e risparmiare sforzo. Io creo le mie soluzioni utilizzando la tecnologia proprietaria e ho diverse esigenze e punti di vista su OOP.
Consiglio di usare almeno una volta il modello di finestra di dialogo di VC++, creare un'applicazione basata sul CDialog di MFC, impostare tutti i tipi di controlli su di esso in modalità visiva, usare le funzioni pronte per capire tutta la potenza di OOP.
E vorrei anche aggiungere che Borland C++ ha classi molto utili per lavorare con Oracle. Ci ho lavorato fino al 2012, ora non so come.
Consiglio di usare almeno una volta il modello di finestra di dialogo di VC++, creare un'applicazione basata sul CDialog di MFC, impostare tutti i tipi di controlli su di esso in modalità visiva, usare funzioni già pronte, per capire tutta la potenza di OOP.
E vorrei anche aggiungere che Borland C++ ha classi molto utili per lavorare con Oracle. Ci ho lavorato fino al 2012, ora non so come.
è la seconda metà del 2019.... ma sia il 20 che il 25 e .... Si discuterà anche sulla necessità di usare OOP?
))))
Se ci piace, lo usiamo, se non ci piace, non lo usiamo.
se ti sei abituato a scrivere programmi usando piccole subroutine scritte in precedenza - scrivi, ti sei alzato dalla parte sbagliata del letto... si mettono tutte queste subroutine nel codice sorgente e si ottiene un gran casino di codice
dare alla gente un sacco di possibilità dell'open source, non è ancora la stessa cosa, rifilare funzionalità al C puro, di nuovo non è la stessa cosa ))))
ZS: Ho il sospetto che alcuni degli sviluppatori leggano comunque il forum... Penso che questo thread li rallegrerà sicuramente! ))))