Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
Actualmente, me gustaría adjuntar la forma VS a .dll a MT5 de una manera simple )))) - Quiero envolver los manejadores de clic de los botones en una clase y llamarlos recorriendo un array de punteros de funciones manejadoras, y quiero tener en el código principal del EA la posibilidad de escribir los mismos nombres de función que en VS, es decir, button2_Click() ....button2_Click()
SZY: Este es un problemade EOP))))
No te ofendas, pero me recuerda mucho:
- Crear estructuras automáticas dentro de una POO dinámica es un sinsentido
¿Así que apilar objetos: myclass obj; no tiene sentido? Entonces, soy un discapacitado :)
Entonces, apilar objetos: myclass obj; no tiene sentido? Así que soy un artesano :)
Hay todo tipo de tareas. Se puede practicar la retórica durante mucho tiempo, si no se describen las tareas específicas, se puede llegar a cualquier cosa...
Sí, los objetos "apilables" (¿automáticos?) son básicamente un sinsentido. En mi humilde opinión, que no es en absoluto la verdad y desde luego no en el último caso...¿Quiere un objeto que no cumpla la función principal de la programación orientada a objetos, la propiedad del polimorfismo? No podrás asignar a una variable de este tipo ningún objeto con propiedades diferentes en función del contenido. No podrás asignar otro objeto a esta "variable" de la lista en absoluto. ¿Por qué necesitas objetos? ¿No es mejor utilizar estructuras en su lugar? Quizás porque las estructuras µl no pueden devolver referencias a sí mismas... Y con ellos comienza una cosa oscura con la creación-destrucción-autocopia constante, etc.
Cómo vivir sin polimorfismo ... ¿Y si digo que podemos prescindir del polimorfismo en >90% de los casos? Tomemos el "principio de inversión de dependencia SOLID", si somos progers decentes, deberíamos crear abstracciones, métodos virtuales en todas partes (lo que conlleva grandes gastos generales, por supuesto). Los adeptos a C# escribirían algo como esto https://pro-prof.com/forums/topic/dependency-inversion-principle. O podríamos tomar plantillas y escribir algo así:
public:
void activate();
void deactivate();
};
template <typename T>
class Button {
Button(T& switchable)
: _switchable(&switchable) {
}
void toggle() {
if (_buttonIsInOnPosition) {
_switchable->deactivate();
_buttonIsInOnPosition = false;
} else {
_switchable->activate();
_buttonIsInOnPosition = true;
}
}
private:
bool _buttonIsInOnPosition{false};
T* _switchable;
}
int main() {
Lamp l;
Button<Lamp> b(l)
b.toggle();
}
Button también es independiente de los detalles, sin todo el polimorfismo y las interfaces. El polimorfismo tiene su propio nicho, pero es mucho más estrecho de lo que dicen.
ZS: bueno, nadie lo prohíbe:
ZS: bueno, nadie lo prohíbe:
Nadie prohíbe todo tipo de muletas y esquematosis, pero ¿por qué? Por ejemplo: será divertido que tu autoobjeto se autodestruya de repente cuando menos te lo esperes, ¿no?
Nadie prohíbe inventarse muletas y esquematosis, pero ¿por qué? Por ejemplo: será divertido que tu auto-objeto se destruya de repente cuando menos lo esperes, ¿no?
Porque un objeto de la pila es mucho más rápido que un objeto del montón(asignación de memoria). ¿Autodestrucción? - Eso es algo nuevo :). Pero a veces es necesario, por supuesto: el número de objetos sólo se conoce en tiempo de ejecución, por ejemplo.
ZS: puedes estar más cómodo de otra manera, es una cuestión personal.
El sentido de la POO no es utilizar el método que elijas para pulsar el botón, que puedes implementar igualmente a través de plantillas o punteros de función, sino simplemente aplicar a cualquier objeto del sistema métodos como list, que permiten autoorganizarse en estructuras de lista y crear selecciones arbitrarias en el momento adecuado sin necesidad de muletas como CArrayObj, etc. y el engorro asociado, sobrecargando métodos como Select, Query, Compare, Sort, etc. (e incluso Clonar/Copiar, cuando cada objeto puede decidir sin tu participación si se copia en una lista/matriz o no, y si se copia, cómo).
Escribí - el polimorfismo tiene su propio nicho, no estoy discutiendo. Pero la práctica demuestra (la mía, al menos) que no es tan significativa. Es mucho más probable que resuelva los problemas con las plantillas.