Una domanda per gli esperti di OOP. - pagina 9

Nuovo commento
 
Roman:

In C++ la comprensione di OOP non arriva subito, ho iniziato a entrare in OOP circa un anno e mezzo dopo aver capito l'approccio procedurale.

Così ho fatto io - poco a poco... e la piena comprensione arriva solo dopo 4-5 anni (e questo è normale per una persona normale)

 
Igor Makanu:


ZS: come posso cambiare il colore del pulsante? - uccidere l'oggetto precedente e creare un nuovo pulsante di colore diverso? - e come ottenere lo stato dei pulsanti? - e se si tratta di uno schema di colori per centinaia di pulsanti - ucciderli tutti di nuovo e crearne altri? ;)

Come funziona in MQ?

classe CButton : public CWndObj :

private:
   CChartObjectButton m_button;             // chart object
..
virtual bool      OnSetColor(void)             { return(m_button.Color(m_color));                }

classe CChartObjectText : public CChartObject

classe CChartObject : public CObject :

bool CChartObject::Color(const color new_color) const
  {
//--- check
   if(m_chart_id==-1)
      return(false);
//--- result
   return(ObjectSetInteger(m_chart_id,m_name,OBJPROP_COLOR,new_color));
  }

classe CWndObj : public CWnd :

color             m_color;               // object color
...
bool CWndObj::Color(const color value)
  {
//--- save new value of parameter
   m_color=value;
//--- call virtual event handler
   return(OnSetColor());
  }


Pertanto, è sufficiente aggiungere una funzione alla classe CButton:

virtual bool      OnSetColor(uint clr)         { return(m_button.Color(clr));  }
 
Nikolai Semko:

E come funziona in MQ?

classe CButton : public CWndObj :

classe CChartObjectText : public CChartObject

classe CChartObject : public CObject :

classe CWndObj : public CWnd :


Quindi tutto quello che dovete fare è aggiungere una funzione alla classe CButton:

Va bene, tutti i metodi OOP sono così, anche in MQL - ho visto il codice sorgente, anche in Delphi, anche in VS - la struttura del codice e la logica è sempre la stessa


Guarda, ho questo canale nei miei iscritti, in generale, ho una visione positiva dell'autore, e c'è anche una ripetizione del tema del tuo video, che ha iniziato la controversia:



e c'è un altro canale che mi piace:


il punto del video è diametralmente opposto in termini di OOP


cancellato il mio post, la discussione richiederà più tempo del previsto, dubito che aspetterò le specifiche, e discutere di "OOP sferico" senza utilità pratica non è la migliore idea

 
Igor Makanu:

Tutte le tecniche di OOP si presentano così, anche in MQL - ho guardato il codice sorgente di SB, anche in Delphi, anche in VS - la struttura del codice e la logica è sempre la stessa


Guarda, ho questo canale nei miei iscritti, in generale, ho una visione positiva dell'autore, e c'è anche una ripetizione del tema del tuo video, che ha iniziato la controversia:


e c'è un altro canale che mi piace:


il punto del video è diametralmente opposto in termini di OOP


cancellato il mio post, la discussione richiederà più tempo di quello che ho pianificato, dubito che aspetterò per le specifiche, e discutere di "OOP sferico" senza uso pratico, non è la migliore idea

Ad essere onesti, io stesso ho appena iniziato ad entrare nell'idea di OOP. Sono d'accordo con Egor Bugaenko più intuitivamente e sulla base della poca esperienza che ho già.
Inoltre so, da un punto di vista puramente filosofico, che la complessità porta spesso a un vicolo cieco, quindi penso che lo schema "il tutto, costituito da componenti semplici" sia più perfetto di "il tutto, costituito da un componente complesso".
Quindi, dopo aver visto questovideo, cercherò di attenermi alla seguente logica e paradigma:
Se ad un certo punto sembra che l'unico modo per risolvere il problema sia attraverso una complicazione ingombrante, allora è il momento di scomporlo in elementi più semplici. Se sembra impossibile, significa che abbiamo scelto un concetto sbagliato e dobbiamo cambiarlo e riscrivere tutto il codice. Penso che questo farà risparmiare tempo in futuro.

 

Ci sono molte varianti. Tutto dipende da ciò di cui avete bisogno e da ciò per cui avete l'immaginazione. Per esempio questo.

class A
  {
public:
                     A(void)  {    };
                    ~A(void)  {    };
  };
  
class B
  {
public:
                     B(void)  {    };
                    ~B(void)  {    };
  };

class C
  {
public:
                     C(void)  {    };
                    ~C(void)  {    };
  };

struct STest
  {
   A a[];
   B b[];
   C c[];
  } test[];
 
Igor Makanu:

cancellato il mio post, la discussione richiederà più tempo del previsto

Gli argomenti di Peter sono un elemento spietato che attira tutto nel suo percorso )), questa è solo un'introduzione, davanti è l'uscita al "core-engine-concept" e Peter ha più esperienza lì ))).

 
Nikolai Semko:

Così dopo aver visto questovideo cercherò di attenermi alla seguente logica e paradigma:
Se ad un certo punto sembra che l'unico modo per risolvere il problema sia attraverso una complicanza ingombrante, allora è il momento di scomporlo in elementi più semplici. Se sembra impossibile, significa che abbiamo scelto un concetto sbagliato e dobbiamo cambiarlo e riscrivere tutto il codice. Penso che risparmierà tempo in futuro.

In teoria questo funzionerà, in pratica - dipende dall'industria in cui lavorerete, a parte lo sviluppo di giochi, dove ogni errore sarà compensato dall'hardware del giocatore o dal software per ufficio dove gli errori non sono critici - li correggeremo o riscriveremo più tardi, ci sono aree dove non potete fare errori, ho lavorato nell'automazione della produzione, e l'automazione non è lampadine, e l'industria energetica - turbine di potenza. Software e automazione "un carro e un carro" - Rack ACS, ACS, controllo delle vibrazioni, console operatore e controller e sensori di attuatori, e tutto funziona contemporaneamente in un complesso, qualsiasi errore nel concetto - nel migliore dei casi è un arresto di emergenza, nel peggiore - distruzione di attrezzature e danni materiali.

Qual è il punto? - Perché il codice deve essere efficace in primo luogo! Tutto ciò che è stato creato per anni è scritto sull'"uso scorretto di OOP", e gli innovatori... bene sedersi con un bicchiere di birra e sognare come l'umanità Microsoft e Google è andato fuori strada - che è cool! ma finora non c'è alcuna responsabilità

 
A100:

Sei stato il primo a scrivermi (il che significa che sei interessato), stavo rispondendo alle domande di Alexey Viktorov sulla Standard Library

La domanda era retorica. Non era chiaro?

 
Alexey Viktorov:

La domanda era retorica. Non era chiaro?

La domanda retorica contiene un'affermazione ovvia - non ho capito di cosa si trattasse. Puoi spiegare?
 
A100:
Una domanda retorica contiene un'affermazione ovvia - non ho capito quale fosse l'affermazione. Puoi spiegare?

Una domanda retorica non può in alcun modo contenere un'affermazione come qualsiasi altra domanda. Una domanda è sempre una domanda. È la stessa domanda, ma non richiede una risposta, non si aspetta una risposta. Una domanda al nulla.

12345678910111213141516...55
Nuovo commento