¿Cómo crear objetos de forma dinámica? (Algunas cosas de POO) - página 3

Nuevo comentario
 

Por cierto, ¿sabes que la versión 1325 ha introducido los punteros a las funciones?
¿Esto hace alguna diferencia en la aplicación de la comunicación triangular?

MQL5: Se ha añadido soporte para punteros a funciones para simplificar la disposición de los modelos de eventos.

Para declarar un puntero a una función, se especifica el tipo "puntero a una función", por ejemplo:

typedef int (*TFunc)(int,int);

Ahora, TFunc es un tipo, y es posible declarar la variable puntero a la función:

TFunc func_ptr;

La variable func_ptr puede almacenar la dirección de la función para declararla posteriormente:

int sub(int x,int y) { return(x-y); }
int add(int x,int y) { return(x+y); }
int neg(int x)       { return(~x);  }

func_ptr=sub;
Print(func_ptr(10,5));

func_ptr=add;
Print(func_ptr(10,5));

func_ptr=neg;           // error: neg is not of  int (int,int) type
Print(func_ptr(10));    // error: there should be two parameters

Los punteros a funciones pueden ser almacenados y pasados como parámetros. No se puede obtener un puntero a un método no estático de la clase.

 
No estoy seguro de si el uso de punteros de función se implementa también con MT4. Si es así, por supuesto, también es posible hacerlo así, siempre y cuando dichos punteros puedan ser gestionados por arrays también, ya que esto es posible con los punteros de clase.
 

probablemente es solo para MT5, y por lo que he visto aun no es para métodos, solo funciones.

De todos modos todavía no entiendo cómo se define la capacidad de terceros dentro de la clase base, por ejemplo en el contexto de la línea de tendencia y el contenedor, donde es el 3er objeto.

Pero voy a tratar de leer de nuevo.

 
Lo que parece que me falta entender del modelo de eventos en conjunción con OO y MQL5, es cual es la clase correcta de despacho de los eventos.
Es decir, cómo y dónde decidir quién (qué clase) recibirá qué (evento).
Está claro que el despachador superior, el nativo del lenguaje, es decir, el ::OnChartEvent del lenguaje se escribe sólo una vez en un proyecto, en la clase de nivel superior.

Entonces, a partir de aquí, ¿cuál es la forma o formas correctas de despachar eventos a diferentes objetos?
¿Debería haber una clase de envío de eventos? ¿Debe hacerse sólo en el ::OnChartEvent basado en sentencias if?
 
Ok, creo que lo he entendido. Hay un verdadero problema de cambio de concepto cuando se viene de procedural a oop.
Si te he entendido bien, entonces lo que quieres decir es una forma de que la CTrendLine informe de su cruce de precios a un objeto heredero de CTrade mediante evento, sin tener que saber de la existencia de CTrade, ¿es así?
 
Amir Yacoby:
Lo que parece que me falta entender del modelo de eventos en conjunción con OO y MQL5, es cual es la clase correcta de despacho de los eventos.
Es decir, cómo y dónde decidir quién (qué clase) recibirá qué (evento).
Está claro que el despachador superior, el nativo del lenguaje, es decir, el ::OnChartEvent del lenguaje se escribe sólo una vez en un proyecto, en la clase de nivel superior.

Entonces, a partir de aquí, ¿cuál es la forma o formas correctas de despachar eventos a diferentes objetos?
¿Debería haber una clase de envío de eventos? ¿Debería hacerse sólo en el ::OnChartEvent basado en sentencias if?
Esto no es una pregunta en absoluto. La POO se basa en los principios de la naturaleza. La tierra no te alimenta, sólo te proporciona los recursos y depende de ti si, cuándo y dónde los necesitas.
 
Amir Yacoby:
Ok, creo que lo he entendido. Hay un verdadero problema de cambio de concepto cuando se viene de procedural a oop.
Si te he entendido bien, entonces lo que quieres decir es una forma de que la CTrendLine informe de su cruce de precios a un objeto heredero de CTrade mediante evento, sin tener que saber de la existencia de CTrade, ¿es así?
Afirmo que sí.
 
Así que en realidad cada CObject ahora tiene un lugar de un objeto que es el receptor de eventos, y también tiene un método de registro para el objeto de escucha para suscribirse como tal y un método de remitente de eventos y un método de controlador de eventos utilizados por el receptor.

Esto es bonito, me recuerda al patrón observador, solo que con el observador tiene más de un posible receptor, el m_recibidor es un array de objetos.

En realidad, una vez quise implementar el observador y debido a la falta de interfaces en MQL o la herencia múltiple no lo hice. No pensé en su buena idea de que el mismo objeto puede forzar la interfaz en ambos lados.


 
Amir Yacoby:
Así que en realidad cada CObject ahora tiene un lugar de un objeto que es el receptor de eventos, y también tiene un método de registro para el objeto de escucha para suscribirse como tal y un método de remitente de eventos y un método de controlador de eventos utilizados por el receptor.

Esto es bonito, me recuerda al patrón observador, solo que con el observador tiene más de un posible receptor, el m_recibidor es un array de objetos.

En realidad, una vez quise implementar el observador y debido a la falta de interfaces en MQL o la herencia múltiple no lo hice. No pensé en su buena idea de que el mismo objeto puede forzar la interfaz en ambos lados.


Solo para animarte, he estado usando mucho los listeners con MQL4.
 
Ovo Cz:
Solo para animarte, he estado usando mucho los listeners con MQL4.

Gracias, pero no me animo (:

Me las arreglé para hacerlo, pero no con un contrato entre el editor y el oyente, es decir, el editor tenía que asumir que el oyente tiene el método de manejo, pero nada obligaba a que lo tuviera.
O bien, tendría que heredar todos los listeners de un objeto listener principal, pero entonces, claro, perdería todo el sentido porque no pueden heredar otras clases.

De todos modos, soy un profesional de la programación, pero definitivamente no en OO donde me falta experiencia hasta ahora, y no estoy compitiendo con ninguno de ustedes experimentados programadores de oo como Doerk.
Lo que he llegado a saber es que ser procedimental te da buena lógica y habilidades de programación pero el cambio es mentalmente duro, especialmente si un orientado al procedimiento como yo se enfrenta a la misión de construir un marco OO, es un estado mental totalmente diferente. Y el framework de la parte GUI es el framework más detallado con muchos eventos de los que ocuparse, creo que estaréis de acuerdo en que entre los frameworks es el más difícil de construir.

12345
Nuevo comentario
Razón de la queja: