¿Cómo crear objetos de forma dinámica? (Algunas cosas de POO) - página 4
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
Absolutamente. Me tomó meses crear mi propio framework de GUI con MQL, sin calcular la experiencia que ya tenía del pasado creando librerías como estas. La parte más difícil no son los eventos, es más la arquitectura y la casi imposibilidad de depurar el código, debido a todos los anidamientos y recursividades pero también por los estados del ratón que ya se invalidan cuando se empieza a depurar.
Por cierto, hace meses ofrecí una colaboración a MQ con estas librerías y desgraciadamente ni siquiera obtuve respuesta. Pero el hecho es que la librería de control estándar es sólo un intento bonito pero también malo en comparación con lo que es realmente posible. Se puede hacer mucho mejor. Tal vez debería ofrecer la biblioteca en el mercado aquí, pero me asusta el montón de trabajo para escribir toda la documentación para ello.
Esto no es una cuestión en absoluto. La OOP se basa en los principios de la naturaleza. La tierra no te alimenta, sólo te proporciona los recursos y tú decides si los necesitas, cuándo y dónde.
¿Quieres decir que, al crear un marco de trabajo, sólo hay que preocuparse por proporcionar los recursos? Lo entiendo, pero de alguna manera me resulta difícil practicarlo porque mi tendencia es demasiado fuerte.
Por ejemplo, si creo un framework y ahora creo el botón y el radiobutton que es una especie de contenedor de botones - cuando llego a crear el radiobutton, mi tendencia es pensar en el objeto dependiente, el botón en este caso, y cómo me comunico con él. Es un hábito de programación procedimental, me pregunto si hiciste el cambio en algún momento de tu pasado de procedimental a OO y puedes indicarme una visión clara de lo que tengo que enfocar en este caso. Porque tiendo a centrarme más en el botón (objeto dependiente) que en el radiobutton.
No estoy seguro de haberlo dejado claro, es sólo una pregunta para señalar las cosas importantes en las que hay que centrarse cuando se crea un nivel en un framework.
¿Puedes decir qué quieres decir con eso? Tengo la sensación general de lo que dices, pero no me queda muy claro.
¿Te refieres a que, al crear un framework, sólo te preocupes por proporcionar los recursos? Lo entiendo, pero de alguna manera me resulta difícil practicarlo porque mi tendencia es demasiado fuerte.
Por ejemplo, si creo un framework y ahora creo el botón y el radiobutton que es una especie de contenedor de botones - cuando llego a crear el radiobutton, mi tendencia es pensar en el objeto dependiente, el botón en este caso, y cómo me comunico con él. Es un hábito de programación procedimental, me pregunto si hiciste el cambio en algún momento de tu pasado de procedimental a OO y puedes indicarme una visión clara de lo que tengo que enfocar en este caso. Porque tiendo a centrarme más en el botón (objeto dependiente) que en el radiobutton.
No sé si lo he dejado claro, es sólo una pregunta para señalar las cosas importantes en las que hay que centrarse a la hora de crear un nivel en un framework.
Tal vez me perdí el punto, pero me gustaría dar mi opinión.
Creo que estás demasiado en la "teoría", y esperar la luz de otra persona. No hay una solución perfecta, hay soluciones y tienes que encontrarla desde tu experiencia y tus necesidades concretas.
Este tema comenzó a partir de un caso práctico, y sabe se convirtió en una oscura discusión sobre OOP. Hay una interesante serie de artículos sobre GUI, deberías echarle un vistazo, y luego intentar construir una interfaz usando la Librería Estándar, y usando la librería de estos artículos, y estudiar el código... o no.
Sólo una sugerencia, ya que realmente no veo que se te pueda ayudar mucho más.
Tal vez me perdí el punto, pero me gustaría dar mi opinión.
Creo que estás demasiado en la "teoría", y esperando la luz de alguien más. No hay una solución perfecta, hay soluciones y tienes que encontrarla desde tu experiencia y tus necesidades concretas.
Este tema comenzó a partir de un caso práctico, y sabe se convirtió en una oscura discusión sobre OOP. Hay una interesante serie de artículos sobre GUI, deberías echarle un vistazo, y luego intentar construir una interfaz usando la Librería Estándar, y usando la librería de estos artículos, y estudiar el código...o no.
Sólo una sugerencia, ya que realmente no veo cómo se te puede ayudar mucho mejor.
Alain, he construido una interfaz y he leído los artículos.
Tal vez no sea el lugar para discutir sobre OO, puede que tengas razón.
Empecé a discutirlo porque Doerk presentó el tema como respuesta al principiante del tema y habló sobre el enfoque correcto de OO.
El propio principiante del tema estaba interesado en la presentación de OO de Doerk, y creo que es natural discutirlo aquí.
Aunque puedes tener razón en que tal vez es demasiado teórico, todavía mi opinión es que el correcto OO no puede sin involucrar algo de teoría y al final se convierte en práctico.
Mi dificultad es el pensamiento correcto de OO, sólo me preguntaba si por casualidad Doerk podría saber de su experiencia la dificultad mental que presenté.
Hay una interesante serie de artículos sobre GUI, deberías echarle un vistazo, y luego intentar construir una interfaz usando la Librería Estándar, y usando la librería de estos artículos, y estudiar el código... o no.
Acabo de descargarlo para ver lo que hace. Y la primera impresión muestra, que hicieron los mismos malos errores que hicieron con la Biblioteca de Control Estándar. Ya el primer ejemplo con una sola ventana de diálogo eleva el uso de la CPU del 10% (sin) al 50-65% (cargado). Esta es ya la mejor prueba de que los autores no tienen la experiencia necesaria para desarrollar una biblioteca de este tipo y que esta no puede ser -una- forma de hacerlo bien.
De todos modos no entiendo por qué MQ no proporciona un marco de trabajo profesional de GUI en lugar de explicar cómo (no) se hace. La mayoría de los programadores de MQL seguramente quieren desarrollar EAs e Indicadores, pero no quieren molestarse con tales cosas.
Además, el panel de su ejemplo está muerto en el probador de la estrategia, y esto es donde todas esas cosas GUI se vuelve absurdo de todos modos. Esto no es ninguna crítica contra usted o contra lo que escribió, yo mismo sé que simplemente no hay mejor material público disponible para MQL aquí.
Alain, he construido una interfaz y he leído los artículos.
Tal vez no es el lugar para discutir OO, puede que tengas razón.
Empecé a discutirlo porque Doerk presentó el tema como respuesta al principiante del tema y habló sobre el enfoque correcto de OO.
El propio principiante del tema estaba interesado en la presentación de OO de Doerk, y creo que es natural discutirlo aquí.
Aunque puedes tener razón en que tal vez es demasiado teórico, todavía mi opinión es que el correcto OO no puede sin involucrar algo de teoría y al final se convierte en práctico.
Mi dificultad es el pensamiento correcto de OO, sólo me preguntaba si por casualidad Doerk podría saber de su experiencia la dificultad mental que presenté.
No hay ningún problema para discutir la POO aquí.
No estoy de acuerdo acerca de su "OO no puede sin involucrar algo de teoría", pero eso no importa.
No hay ningún problema en discutir la POO aquí.
No estoy de acuerdo con tu "OO no puede sin involucrar alguna teoría", pero eso no importa.
Acabo de descargarlo para ver qué hace. Y la primera impresión muestra que han cometido los mismos errores que cometieron con la biblioteca de control estándar. Ya el primer ejemplo con una sola ventana de diálogo eleva el uso de la CPU del 10% (sin) al 50-65% (cargado). Esta es ya la mejor prueba de que los autores no tienen la experiencia necesaria para desarrollar una biblioteca de este tipo y que esta no puede ser -una- forma de hacerlo bien.
De todos modos no entiendo por qué MQ no proporciona un marco de trabajo profesional de GUI en lugar de explicar cómo (no) se hace. La mayoría de los programadores de MQL seguramente quieren desarrollar EAs e Indicadores, pero no quieren molestarse con tales cosas.
Además, el panel de su ejemplo está muerto en el probador de la estrategia, y esto es donde todas esas cosas GUI se vuelve absurdo de todos modos. Esto no es una crítica contra usted o contra lo que escribió, yo mismo sé que simplemente no hay mejores cosas públicas disponibles para MQL aquí.
Doerk, lo más probable es que tengas razón, pero ese no es mi punto.
Deberías escribir un ejemplo concreto de por qué ocurre este problema con la CPU, explicar a Anatoli (autor de los artículos) cuál es el problema. Siento decir que hasta ahora todo lo que has dicho es casi inútil, incluso si tienes 100% de razón. Es demasiado general y teórico. No te ofendas.
El problema es que este tema es demasiado complejo para dar instrucciones exactas. Y es por eso que estoy tratando de proporcionar algunas ideas y posibles maneras a los que están interesados. Lamentablemente no tengo tiempo para escribir un artículo ni para publicar una biblioteca completamente documentada. Lo siento.