Una domanda per gli esperti di OOP. - pagina 6

Nuovo commento
 
Реter Konow:

Il codice non è portabile - questa è la sua peculiarità. Non è destinato ad essere portatile. Ha un altro scopo. Bene, l'ambito globale delle variabili è uno strumento potente per implementare meccanismi complessi. Bisogna solo sapere come usarlo. Quando la gente mi parla di errori e bug nascosti, mi confondo. Non ho mai avuto alcun bug legato alla visibilità delle variabili globali. In una parola, per niente.

Il problema con le variabili globali è che se il progetto è abbastanza grande e i cambiamenti nello stato di queste variabili provengono da molte sezioni di codice, è abbastanza lungo cercare i bug.

Esempio. Si trova un bug perché il valore di una variabile globale non è chiaramente quello che dovrebbe essere. Ci sono un paio di dozzine di file e 100500 linee di codice nel progetto. Nessuno ricorda quanti frammenti di codice cambia questa variabile. Il risultato è un barattolo di caffè e un sonno profondo con la testa incastrata nella tastiera.

E ora la stessa cosa, ma OOP. Abbiamo scritto il codice correttamente e tutti i campi sono privati. Di conseguenza, direttamente si cambia solo nei metodi di classe, e dall'esterno solo con il metodo Set. Di conseguenza, mettiamo dei breakpoint sul metodo Set e su quanti metodi ci sono nella classe, dove viene cambiato il campo, e possiamo facilmente tracciare dove vengono fatte le modifiche e dove sono state cambiate in modo errato.

 
Реter Konow:

Non ho mai avuto nessun bug legato alla visibilità delle variabili globali. Niente affatto.

Non so nemmeno come convincervi dell'ovvio, ma probabilmente non dovrei, non vengo pagato per questo, vero?

Beh, se vuoi una lode, eccoti servito:

Peter! Così si fa!

))))

 
Vladimir Simakov:

Il problema con le variabili globali è che se il progetto è abbastanza grande e i cambiamenti nello stato di queste variabili provengono da molte sezioni di codice, è abbastanza lungo cercare i bug.

Esempio. Si trova un bug perché il valore di una variabile globale non è chiaramente quello che dovrebbe essere. Ci sono un paio di dozzine di file e 100500 linee di codice nel progetto. Nessuno ricorda quanti frammenti di codice cambia questa variabile. Il risultato è un barattolo di caffè e un sonno profondo con la testa bloccata nella tastiera.

E ora abbiamo la stessa cosa, ma è OOP. Abbiamo scritto il codice correttamente e tutti i campi sono privati. Di conseguenza sarà cambiato direttamente solo nei metodi di classe, ma dall'esterno solo dal metodo Set. Di conseguenza, mettiamo dei breakpoint sul metodo Set e su quanti metodi ci sono nella classe, dove viene cambiato il campo, e possiamo facilmente tracciare dove vengono fatte le modifiche e dove sono state cambiate in modo errato.

Dalla pratica. Ho più di 100 file collegati nel mio progetto. Alcuni hanno più di 2000 linee di codice. Le variabili globali sono usate ovunque. Non ho mai avuto alcun bug legato alla loro globalità. Forse mi sono solo adattato?)) Forse non ci sono bug perché tutte le variabili sono in russo e tutti i nomi sono significativi. Nessun sdf o iukj. Pertanto, non ho errori associati ad essi. In generale, le variabili globali sono utilizzate per i flag di eventi globali, ad esempio l'apertura di una finestra, il clic sui pulsanti del mouse, l'espansione di un elenco antico, ecc. Inoltre, per la messa a fuoco. In altre parole, il mouse attraversa la GUI, e i numeri di tutti gli oggetti ed elementi e le loro proprietà sono scritti in variabili globali, e i blocchi richiesti sono chiamati da OnChartEvent, che lavorano immediatamente con gli oggetti ed elementi a fuoco. Questo è molto conveniente.
 
Igor Makanu:

Non so nemmeno come convincervi dell'ovvio, ma probabilmente non dovrei, non vengo pagato per questo, vero?

Beh, se vuoi una lode, eccoti servito:

Peter! Così si fa!

))))

Non sto ottenendo nulla. Beh, forse capendo che non solo con OOP si possono scrivere progetti fighi. E non è solo la padronanza di OOP che è un segno di uno sviluppatore. Non discuto che si possano risolvere molti compiti con OOP. Ma ci sono altri approcci.
 
Grazie a tutti per aver partecipato alla discussione. Cercherò di entrare in OOP per confrontare realmente le capacità dei due approcci. Sono interessato alla gerarchia che l'OOP può fornire, e se la sua utilità non è sepolta sotto la sua sintassi, la adotterò sicuramente.
 
Реter Konow:
Beh, forse la comprensione del fatto che non solo con OOP si possono scrivere progetti interessanti. E non solo essere abile in OOP è un segno di uno sviluppatore. Non discuto che si possano risolvere molti compiti con OOP. Ma ci sono altri approcci.

non si tratta di OOP, si tratta dei principi di scrittura del codice stesso, questa è la seconda volta che ne parlo e@Vladimir Simakov ha scritto un esempio sopra

Se volete usare la visibilità delle variabili globali - nessun problema, nessuno lo vieta, potete farlo - ma in silenzio, mentre nessuno guarda! )))

ma come stile permanentemente usato per scrivere programmi è un male, e più codice c'è, più c'è questo male! - così hai spiegato? )))

SZY: un altro colpo di prova - guarda l'aiuto di MQL, vedi che tutte le funzioni sono fatte come unità separate, completamente indipendenti? - passati i parametri = ottenuto il risultato! Pensi che i programmatori di Metakvot stiano di nuovo sbagliando tutto? Dovremmo usare qualche stile libero di scrivere le funzioni - qui nello scope globale, e qui l'utente chiamerà la funzione e otterrà il risultato! )))) - lo stile procedurale (dove ogni subroutine è un blocco logico completo) è il codice giusto, scrivere i codici correttamente! non il giusto ... beh, verrà da solo "quando ne avrai bisogno in fretta" ;)

 
Реter Konow:
Dalla pratica. Ho più di 100 file collegati nel mio progetto. Alcuni hanno più di 2000 linee di codice. Le variabili globali sono usate ovunque. Non ho mai avuto alcun bug legato alla loro globalità. Forse mi sono semplicemente adattato a questo?))

Lei ha solo un'ottima memoria, non tutti sono così fortunati. Ricordo già debolmente quali variabili ho inserito oggi. Non ricordo quali di una settimana fa. Ma questo non è un problema, sono tutti locali e l'accesso ai campi di qualsiasi oggetto è solo attraverso funzioni appropriate. OOP mi permette di non ricordare molte cose, l'ho già detto più di una volta - idealmente, in qualsiasi luogo del codice si dovrebbe avere accesso solo a ciò di cui si ha bisogno e non più variabili - così anche se si vuole non si può cambiare ciò che non si dovrebbe. E quando ne avrete davvero bisogno, dovrete capire perché non potete accedere a una variabile- è solo una svista, o più spesso è una variabile che ha bisogno di lavoro aggiuntivo per essere modificata. Se fosse immediatamente disponibile per voi, ve ne dimentichereste, e poi ci vorrebbe molto tempo per capire perché il programma non funziona o non funziona come volete.

 
Реter Konow:
Non sto cercando di ottenere qualcosa. Beh, forse capire che non è solo con OOP che si possono scrivere progetti fighi. E non è solo la padronanza di OOP che è un segno di uno sviluppatore. Non discuto che si possano risolvere molti compiti con OOP. Ma ci sono altri approcci.

Un'altra cosa buona di OOP è che si acquisiscono gradualmente librerie di classi, specialmente quelle veramente universali, che rimangono con voi per tutta la vita e facilitano questa vita.

Da un progetto reale, funziona davvero. Non c'è nessun problema qui, devi solo monitorare il numero e lo stato degli ordini/posizioni disponibili. Questa funzione controlla solo che la posizione/ordine non sia chiusa/annullata e la rimuove dalla lista dopo la chiusura.

void OrdersControl(){
   for (CTrade* it=gPos.Begine();
        it!=NULL;
        it=it.Control()?gPos.Next():gPos.Delete());}

Dove gPos è CList<CTrade> gPos

CList e CTrade non fanno parte della libreria standard.

CTrade è ereditato dalla mia libreria CPosition.

In realtà qui sotto c'è tutto il CTrade di cui avete bisogno solo per rendere leggibile il codice del vostro progetto:

#include "..\Header.mqh"

#ifndef _C_TRADE_
#define _C_TRADE_

#include "..\..\..\Shared Projects\mqlLib\Objects\Trade\CPosition.mqh"

class CTrade:public CPosition
  {
public:
                     CTrade(double mVolume,int mDirect,double mSL,double mTP);
   bool              Control() {return !( CPosition::Control()&TRADE_FINISH);}
  };
//-------------------------------------------------------------------------------------
void CTrade::CTrade(double mVolume,int mDirect,double mSL,double mTP):
   CPosition(NULL,
             mDirect>0?OP_BUY:OP_SELL,
             mVolume,
             0.0,
             mSL,
             mTP)
{}

#endif
L'intera implementazione della gestione dell'ordine/posizione è nascosta nel file di libreria multipiattaforma CPosition.
 
Реter Konow:
Grazie a tutti per aver partecipato alla discussione. Cercherò di approfondire l'OOP per confrontare realmente le capacità dei due approcci. Sono interessato alla gerarchia che l'OOP può fornire, e se la sua utilità non è sepolta sotto la sua sintassi, la adotterò sicuramente.

Aiuta te stesso su YouTube. Ci sono un sacco di cose. Soprattutto in inglese, con il quale sei bravo.


Non risparmiare 45 minuti, Peter. All'inizio è molto importante capire di cosa sta parlando questo tizio. Molte persone probabilmente discuteranno con lui, ma in generale ha ragione:


 
Nikolai Semko:

Aiuta te stesso su YouTube. Ci sono un sacco di cose. Soprattutto in inglese, con il quale sei bravo.


Non risparmiare 45 minuti, Peter. All'inizio è molto importante capire di cosa sta parlando questo tizio. Molte persone probabilmente discuteranno con lui, ma in generale ha ragione:


Grazie, Nikolai. Terrò gli occhi aperti.
12345678910111213...55
Nuovo commento