Preguntas de POO (Programación Orientada a Objetos) - página 7

 
Zhunko:

Vasily, un ejemplo, por favor.

Sólo conozco un caso en el que hay que asignar memoria y se necesita un puntero a la misma.

Estoy seguro de que casi siempre se puede prescindir de él. Es conveniente no utilizar la gestión manual de la memoria. Siempre hay una biblioteca estándar que ya ha resuelto estos problemas.


enum ENUM_CLASS_TYPE
{
   CLASS_PARENT,
   CLASS_CHILD_1,
   CLASS_CHILD_2
};

class Parent
{
   public:
      ENUM_CLASS_TYPE(void){return classType;}
      virtual string GetName(){return "Base";}
   protected:
      Parent(ENUM_CLASS_TYPE type){classType = type;}
   private:
      ENUM_CLASS_TYPE classType;
};

class Child1 : public Parent
{
   public:
      Child1() : Parent(CLASS_CHILD_1){;}
      void MethodChild1(){;}
};

class Child2 : public Parent
{
   public:
      Child2() : Parent(CLASS_CHILD_2){;}
      void MethodChild2(){;}
};

int Start()
{
   Parent* parent = new Child1();
   switch(parent.GetType())
   {
      case CLASS_CHILD_1:
      {
          Child1* ch = parent;
          ch.MethodChild2();
          break;
      }
      case CLASS_CHILD_2:
      {
          Child1* ch = parent;
          ch.MethodChild2();
          break;
      }
   }
}
 
TheXpert:
La presencia de la identificación del tipo dinámico suele indicar la arquitectura de muletas del proyecto.


La presencia de identificación de tipos dinámicos indica un alto grado de polimorfismo y un mayor nivel de abstracción. Aumenta la capacidad de gestión y la escalabilidad del proyecto. Permite trabajar con el código a nivel de interfaz y anima al programador a no entrar en detalles de implementación.
 
Vasily, creo que tu ejemplo está fuera de lugar. Existen plantillas (macros en µl), que pueden resolver muchos problemas en tiempo de compilación. Y si tienes que hacer una conversión a la baja, no has diseñado bien el programa (hasta Straustrup lo dijo).
 
Pavlick:
Vasily, creo que tu ejemplo está fuera de lugar. Existen plantillas (macros en µl), que pueden resolver muchos problemas en la fase de compilación. Y si tienes que hacer una conversión a la baja, has diseñado mal el programa (hasta Straustrup lo ha dicho).

¿Qué hay de malo en el cambio a la baja con un control estricto del tipo? Straustrup dijo esto cuando no había ningún tipo de control. Ahora, si se conoce el tipo derivado, se puede garantizar la conversión antes de que se inicie y así evitar errores en tiempo de ejecución.

Pero las ventajas de la conversión a la baja son evidentes. La principal es que funciona a nivel de interfaz. Si el constructor de una clase base está cerrado en el ámbito protegido, se trata de una clase interfaz y abstracta y podemos trabajar con ella a su nivel sin tener que conocer la implementación refinada de sus descendientes. Pero si implementamos un comportamiento polimórfico en función del tipo de instancia, seguramente podremos especificar la implementación de la instancia correspondiente y, por ejemplo, llamar a su método único. Con las funciones virtuales ni siquiera necesitaremos la conversión de tipos. Después de todo, las funciones virtuales llamarán a la implementación específica "entre bastidores".

 
C-4:

... Con las funciones virtuales, ni siquiera será necesaria una conversión de tipo. Al fin y al cabo, las funciones virtuales llamarán a una implementación concreta "entre bastidores".


No tengo nada en contra del resaltado. En el ejemplo has adoptado un enfoque diferente.
C-4:

¿Qué hay de malo en la caída del reparto cuando los tipos están estrictamente controlados?

Si lo escribes correctamente, simplemente no lo necesitas.

P.D: No estoy metiendo en la misma botella la identificación del tipo de samapal y el mecanismo de la función virtual.

 

Un ejemplo de una aplicación MQL real:

Дана строка таблицы состоящая из ячеек нескольких типов. Часть из них являются обычным полями текста OBJ_TEXT, часть - кнопками OBJ_BUTTON а часть - ячейками, в которых текст можно редактировать (OBJ_EDIT). Значения введенное в ячейку типа OBJ_EDIT запоминается, и в случае его корректности формируется некий приказ, который отправляется на выполнение внешней системе. В промежутке времени между отправкой приказа и получения ответа от системы необходимо заблокировать строку таблицы таким образом, что бы все ячейки с возможностью редактирования в них текста больше не позволяли вводить в них текст. Все кнопки входящие в строку таблицы не позволяли нажимать на себя, а в целом, все ячейки в которых есть текст, должны были бы изменить его цвет на красный, сигнализируя тем самым о своей блокировке. Строки входящие в таблицу не идентичны друг другу и не содержат регулярной структуры. Одна строка может содержать кнопку, тогда как другая нет. Одна строка может содержать какой-либо столбец, а другая нет и т.д.

Me gustaría escuchar las opiniones de los expertos sobre cómo resolverían ese problema. Personalmente lo resolví utilizando la identificación de tipos dinámicos, el patrón "método del patrón" y las conversiones por pasos. Se resolvió tan bien que finalmente me permitió crear complejas tablas interactivas con elementos irregulares y totalmente personalizables. Los resultados son tan tangibles que me parece ingenuo afirmar que de "la identificación dinámica es una muleta" y que "la conversión a la baja es mala".

p.d. Pavlick, por cierto, todavía no has contestado qué es exactamente lo que está mal en la conversión a la baja.

 

No, estoy lejos de ser un experto. Lo que he dicho sobre el engranaje de reducción es mi experiencia, me esfuerzo por escribirlo así + lo confirman personas a las que respeto. Escribir un programa para demostrar algo es una pérdida de tiempo.

Pavlick, por cierto, todavía no has contestado qué es exactamente lo que hace que la reducción de personal sea mala.

Es difícil de explicar. Lo entiendo, pero no puedo decirlo). Los libros probablemente lo explicarán mejor.

 
C-4:
enum ENUM_CLASS_TYPE
{
   CLASS_PARENT,
   CLASS_CHILD_1,
   CLASS_CHILD_2
};

class Parent
{
   public:
      ENUM_CLASS_TYPE(void){return classType;}
      virtual string GetName(){return "Base";}
   protected:
      Parent(ENUM_CLASS_TYPE type){classType = type;}
   private:
      ENUM_CLASS_TYPE classType;
};

class Child1 : public Parent
{
   public:
      Child1() : Parent(CLASS_CHILD_1){;}
      void MethodChild1(){;}
};

class Child2 : public Parent
{
   public:
      Child2() : Parent(CLASS_CHILD_2){;}
      void MethodChild2(){;}
};

int Start()
{
   Parent* parent = new Child1();
   switch(parent.GetType())
   {
      case CLASS_CHILD_1:
      {
          Child1* ch = parent;
          ch.MethodChild2(); // Это не ошибка?
          break;
      }
      case CLASS_CHILD_2:
      {
          Child1* ch = parent;// Это не ошибка?

          ch.MethodChild2();
          break;
      }
   }
}

Aunque no sea un error, hay plantillas y typeid().
 
Pavlick:

No, estoy lejos de ser un experto.

Pero Stroustrup sí. Y también muchos otros. Estás diciendo todas las cosas correctas.
 
Typeid() desafortunadamente no existe, y la fuerza de las plantillas es la identificación estática. Diferentes problemas se resuelven con diferentes métodos y decir que un método es malo y el otro es bueno es una suposición ahuld.
Razón de la queja: