Una pregunta para los expertos en POO. - página 9

Nuevo comentario
 
Roman:

En C++ la comprensión de la POO no llega de golpe, empecé a meterme en la POO un año y medio después de entender el enfoque procedimental.

Yo también lo hice, poco a poco... y la comprensión total sólo llega después de 4-5 años (y esto es normal para una persona normal)

 
Igor Makanu:


ZS: ¿Cómo puedo cambiar el color del botón? - matar el objeto anterior y crear un nuevo botón de un color diferente? - ¿y cómo conseguir el estado de los botones? - y si se trata de una combinación de colores para cientos de botones - matarlos a todos de nuevo y crear otros... ;)

¿Cómo funciona esto en MQ?

class CButton : public CWndObj :

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

class CChartObjectText : public CChartObject

class 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));
  }

class 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());
  }


Por lo tanto, basta con añadir una función a la clase CButton:

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

¿Y cómo funciona esto en MQ?

class CButton : public CWndObj :

class CChartObjectText : public CChartObject

class CChartObject : public CObject :

class CWndObj : public CWnd :


Así que todo lo que tienes que hacer es añadir una función a la clase CButton:

Muy bien, todos los métodos OOP se ven así, incluso en MQL - he visto el código fuente, incluso en Delphi, incluso en VS - la estructura del código y la lógica es siempre la misma


Mira, tengo este canal en mis suscriptores, en general, tengo una visión positiva del autor, e incluso se repite el tema de tu video, que inició la disputa:



y hay otro canal que me gusta:


el punto del video es diametralmente opuesto en términos de OOP


borrado mi post, la discusión se alargará más de lo previsto, dudo que espere a que se concreten, y discutir sobre "OOP esférica" sin utilidad práctica no es la mejor idea

 
Igor Makanu:

Todas las técnicas de POO se parecen a esto, incluso en MQL - he visto el código fuente de SB, incluso en Delphi, incluso en VS - la estructura del código y la lógica es siempre la misma


Mira, tengo este canal en mis suscriptores, en general, tengo una visión positiva del autor, e incluso se repite el tema de tu vídeo, que inició la disputa:


y hay otro canal que me gusta:


el punto del video es diametralmente opuesto en términos de OOP


borrado mi post, la discusión tomará más tiempo de lo que planeo, dudo que espere a que se especifique, y discutir "OOP esférica" sin uso práctico, no es la mejor idea

Para ser honesto, yo mismo estoy empezando a entender la idea de OOP. Estoy de acuerdo con Egor Bugaenko de forma más intuitiva y basándome en la poca experiencia que tengo.
Por otra parte, sé, desde un punto de vista puramente filosófico, que la complejidad suele llevar a un callejón sin salida, por lo que creo que el esquema "el todo, formado por componentes simples" es más perfecto que "el todo, formado por un componente complejo".
Así que después de ver estevídeo, intentaré ceñirme a la siguiente lógica y paradigma:
Si en algún momento parece que la única forma de resolver el problema es a través de una complicación engorrosa, entonces es el momento de descomponerlo en elementos más simples. Si parece imposible, significa que hemos elegido un concepto equivocado y debemos cambiarlo y reescribir todo el código. Creo que esto ahorrará tiempo en el futuro.

 

Hay muchas variantes. Todo depende de lo que necesites y de la imaginación que tengas. Por ejemplo esto.

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:

borrado mi post, la discusión se alargará más de lo previsto

Los temas de Peter son un elemento implacable que arrastra todo a su paso )), esto es sólo una introducción, adelante está la salida al "núcleo-motor-concepto" y Peter tiene más experiencia allí ))).

 
Nikolai Semko:

Así que después de ver estevídeo intentaré ceñirme a la siguiente lógica y paradigma:
Si en algún momento parece que la única forma de resolver el problema es mediante una complicación engorrosa, entonces es el momento de descomponerlo en elementos más sencillos. Si parece imposible, significa que hemos elegido un concepto erróneo y tenemos que cambiarlo y reescribir todo el código. Creo que en el futuro se ahorrará tiempo.

En teoría esto funcionará, en la práctica - depende de la industria en la que se va a trabajar, aparte del desarrollo de juegos, donde cualquier error será compensado por el hardware del jugador o el software de oficina donde los errores no son críticos - vamos a arreglar o reescribir más tarde, hay áreas en las que no se puede cometer errores, he trabajado en la automatización de la producción, y la automatización no es bombillas, y la industria de la energía - turbinas de energía. Software y automatización "un vagón y un carro" - Rack ACS, ACS, control de vibración, consolas de operador, y los controladores y sensores de los actuadores, y todo funciona simultáneamente en un complejo, cualquier error en el concepto - en el mejor de los casos es una parada de emergencia, en el peor - la destrucción de equipos y daños a la propiedad.

¿Qué sentido tiene? - Porque el código debe ser eficaz en primer lugar. Todo lo que se ha creado durante años está escrito sobre el "uso incorrecto de la POO", y los innovadores... pues siéntese con un vaso de cerveza y sueñe con cómo la humanidad Microsoft y Google se extraviaron - ¡eso es genial! pero hasta ahora no hay ninguna responsabilidad

 
A100:

Fuiste el primero en escribirme (lo que significa que estás preocupado), estaba respondiendo a las preguntas de Alexey Viktorov sobre la Biblioteca Estándar

La pregunta era retórica. ¿No estaba claro?

 
Alexey Viktorov:

La pregunta era retórica. ¿No ha quedado claro?

La pregunta retórica contiene una afirmación obvia: no he entendido a qué se refiere la afirmación. ¿Puede explicarlo?
 
A100:
Una pregunta retórica contiene una afirmación obvia: no entendí cuál era la afirmación. ¿Puede explicarlo?

Una pregunta retórica no puede contener en ningún caso una afirmación como cualquier pregunta. Una pregunta sigue siendo una pregunta. Es la misma pregunta, pero no requiere una respuesta, no espera una respuesta. Una pregunta a ninguna parte.

12345678910111213141516...55
Nuevo comentario
Razón de la queja: