Una domanda per gli esperti di OOP. - pagina 11

Nuovo commento
 
Petros Shatakhtsyan:

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.

Questo è il punto, potrebbe. 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.
 
Реter Konow:

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.

 
Aliaksandr Hryshyn:
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.

 
Petros Shatakhtsyan:

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.

 
Petros Shatakhtsyan:

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 effettivo è di un centinaio di righe e il restante paio di migliaia è una libreria scritta e debuggata da tempo? )))
 
Vladimir Simakov:
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.

 
Georgiy Merts:
....

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.

 
Реter Konow:

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.

 
Petros Shatakhtsyan:

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.

In questa discussione, per potere intendiamo cose diverse. Per voi, la potenza si esprime come assemblaggio facile e veloce di pezzi di codice già pronti dalle librerie, di cui ce ne sono già molte. Le costruzioni leggere sono anche Power. Ma è diverso. Sto parlando del potere di sviluppare nuove soluzioni. Da zero. Il potere di far crescere un programma nell'ambiente di sviluppo senza pezzi di codice già pronti. Dopo tutto, non fanno il porting delle librerie grafiche C++ su MQL. Avete dovuto sviluppare le vostre soluzioni dello stesso livello. E qui la potenza non è testata dalla velocità di costruzione ma dalla velocità di sviluppo del programma. Ho impiegato due anni e mezzo per creare il mio linguaggio di markup da zero. La mia API. Questo è più delle librerie MQL grafiche. Sono arrivato molto vicino a creare un costruttore visivo. E questo, un indicatore della potenza dell'approccio. È un peccato che nessuno qui ne abbia bisogno...
 

è 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! ))))

1...456789101112131415161718...55
Nuovo commento