Mi enfoque. El núcleo es el motor. - página 138
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
"Ampliar el potencial creativo de los partidarios de la OOP", Vereshchagin, Canvas, Oil
Gracias a todos por los posts informativos.
Hoy vamos a probar la comunicación entre el EA y el motor a través de los recursos. Acabo de completarlo. También debería funcionar en el probador.
Estás trabajando con la clase CCanvas. Es el único en su desarrollo.
La clase es parte del sistema. Si es UNO, no hay sistema.
Entonces, ¿por qué crear objetos de clase y referirse a sus funciones mediante reglas de POO?
PRÁCTICAMENTE no necesitas OOP al tratar con una clase.
Pero, sí se utiliza la POO al tratar con UNA clase. Sin embargo, no necesitas OOP.
Peter, en POO, los objetos de clase se crean para poder trabajar con muchos objetos que no dependen unos de otros. Cuando se trabaja con CCanvas y se tiene un solo gráfico todo está bien, OOP no es realmente necesario aquí. Pero cuando necesitas mostrar varios gráficos en diferentes áreas, es difícil hacerlo sin OOP y creando múltiples instancias de CCanvas.
O un ejemplo más. Recientemente me han pedido que modifique un Asesor Experto de procedimiento para que pueda operar en diferentes símbolos simultáneamente (ejecutándose en un gráfico). El estilo procedimental habría requerido largos y complejos esfuerzos para hacer que se negocie independientemente en diferentes símbolos al mismo tiempo. Por el contrario, simplemente coloqué todo el código de procedimiento en una clase y creé tres ejemplares. Especifiqué un conjunto individual de ajustes para cada uno de ellos, incluyendo el símbolo de trabajo, etc. El código funcionó correctamente en el primer intento. El código ha funcionado como debía en el primer intento. El usuario quedó satisfecho.
Incluso usted está utilizando OOP en su núcleo. Aunque lo haces implícitamente:
Para no quedarme sin argumentos, permítanme finalmente darles un ejemplo de ese mismo "núcleo". Más concretamente, se trata de un archivo de arranque. Hay varios núcleos en él.
Le recuerdo que se imprime automáticamente, basándose en el código KIB. Luego se coloca en el motor. A continuación, el motor trabaja con él.
Cada uno de sus núcleos es una instancia de una clase en términos OOP. Lo llamen como lo llamen, pero es un elemento de OOP. Pero, por desgracia, este elemento es de fabricación propia e inferior en poder conceptual a lo que ya ha sido inventado y pulido por miles de mentes no capacitadas.
¿Qué, gente, todos convenciendo a Peter de los beneficios de la OOP?
¡No lo convencerás! Si tuvieras una memoria como la suya, te preguntarías por qué todo esto de la POO es tan complicado cuando se puede hacer todo mucho más sencillo... Hacemos que todas las variables sean globales, de acceso directo desde cualquier lugar, sin prohibiciones ni restricciones: ¡qué bien!
Esto es para aquellos que en su débil mente pueden olvidar lo que escribieron hace diez años - es necesario que el compilador y el lenguaje lo limiten en todos los sentidos. Y cuando recuerdas exactamente por qué y para qué escribiste tal o cual construcción en tu código, que tiene muchos años, la POO es sólo la quinta rueda del carro.
El problema de Peter no está en la elección "enfoque OOP o procedimental", el problema de Peter está en el público objetivo. La falta de personas que, por un lado, sean buenas programadoras y, por otro, prefieran cambiar de mano. No observo a esas personas.
1. Exactamente. Se puede prescribir un número limitado de elementos en el constructor. Por lo tanto, una tabla dinámica debe constar de un número limitado de filas, pero al mismo tiempo, no tener restricciones. La solución sólo consiste en crear matrices especiales para los parámetros añadidos y desplazar sus valores por las celdas de la tabla.
2. Sí. El constructor crea el núcleo para el motor basado en el código que has citado. + imprime los archivos de conexión. Luego, puse el núcleo en el motor (DRIVE). Después de eso, el motor puede reproducir el GUI deseado. Los archivos de emparejamiento se conectan al EA y comienzan a interactuar con él.
Resulta que cada vez para una nueva gui hay que hacer cambios en el motor (dotarlo del kernel GUI apropiado). Creo que es una solución fundamentalmente errónea. Imagine que hay cientos de usuarios de su motor. Pero el motor alojado en el Mercado o en otro lugar es sólo uno. ¿Cómo lo harás en este caso? ¿Para que cada usuario coloque un motor específico, que debe descargar por sí mismo? ¿Cómo se prepara el núcleo gui para el motor? ¿Proporcionará a cada usuario un motor individual? - Esto se convertirá rápidamente en una pesadilla. Así que su solución no es escalable.
Peter, en POO, los objetos de clase se crean para poder trabajar con múltiples objetos que no dependen unos de otros. Cuando trabajas con CCanvas y tienes una sola gráfica todo está bien, realmente no necesitas OOP aquí. Pero cuando se necesita mostrar varias parcelas en diferentes áreas, es difícil de hacer sin OOP y la creación de múltiples instancias de CCanvas.
O un ejemplo más. Recientemente me han pedido que modifique un Asesor Experto de procedimiento para que pueda operar en diferentes símbolos simultáneamente (ejecutándose en un gráfico). El estilo procedimental habría requerido largos y complejos esfuerzos para hacer que se negocie independientemente en diferentes símbolos al mismo tiempo. Por el contrario, simplemente coloqué todo el código de procedimiento en una clase y creé tres ejemplares. Especifiqué un conjunto individual de ajustes para cada uno de ellos, incluyendo el símbolo de trabajo, etc. El código funcionó correctamente en el primer intento. El código ha funcionado como debía en el primer intento. El usuario quedó satisfecho.
Incluso usted está utilizando OOP en su núcleo. Aunque lo haces implícitamente:
Cada uno de sus núcleos es una instancia de una clase en términos OOP. Y lo llames como lo llames, es un elemento de OOP. Pero, por desgracia, este elemento se hace a sí mismo y cede en su poder conceptual a lo que ya ha sido inventado y pulido por miles de mentes no experimentadas.
Vasily, entiendo por qué las funciones de dibujo se convierten en una clase. Porque hay otros conjuntos de funciones además de ellos.
Pero mi pregunta era un poco diferente. ¿Por qué, exactamente, usaría Nikolai llamar a las funciones de dibujo a través de una clase, si no usó ninguna otra clase. Sólo dibuja.
El objetivo de la pregunta era exactamente ese.
He insistido en la inutilidad de esta acción desde el punto de vista de la lógica, y en que él no es consciente de ello.
También subrayé que el uso de la POO es a menudo poco razonable por el tamaño de las tareas a resolver. Al fin y al cabo, la POO requiere una clasificación ramificada, y si no existe tal clasificación, ¿merece la pena crearla a propósito?
La cuestión es que el desarrollador debe guiarse por los requisitos de los mecanismos, no de las herramientas.
Peter, en POO, los objetos de clase se crean para poder trabajar con múltiples objetos que no dependen unos de otros. Cuando trabajas con CCanvas y tienes una sola gráfica todo está bien, realmente no necesitas OOP aquí. Pero cuando se necesita mostrar varias parcelas en diferentes áreas, es difícil de hacer sin OOP y la creación de múltiples instancias de CCanvas.
O un ejemplo más. Recientemente me han pedido que modifique un Asesor Experto de procedimiento para que pueda operar en diferentes símbolos simultáneamente (ejecutándose en un gráfico). El estilo procedimental habría requerido largos y complejos esfuerzos para hacer que se negocie independientemente en diferentes símbolos al mismo tiempo. Por el contrario, simplemente coloqué todo el código de procedimiento en una clase y creé tres ejemplares. Especifiqué un conjunto individual de ajustes para cada uno de ellos, incluyendo el símbolo de trabajo, etc. El código funcionó correctamente en el primer intento. El código ha funcionado como debía en el primer intento. El usuario quedó satisfecho.
Incluso usted está utilizando OOP en su núcleo. Aunque lo haces implícitamente:
Cada uno de sus núcleos es una instancia de una clase en términos OOP. Y lo llames como lo llames, es un elemento de OOP. Pero, por desgracia, este elemento se hace a sí mismo y cede en su poder conceptual a lo ya inventado y pulido por miles de mentes incompetentes.
Estás perdiendo el tiempo. En primer lugar, tu ejemplo con el asesor de Perth es una cataplasma - no sabe escribir expertos, no entiende lo que hay y cuál es el punto, y no puede entender tu ejemplo tan claro - ya verás, él, moviendo los ojos, te dirá lo mismo que le dijo a Nikolay. En segundo lugar, le darás una excusa para empujar su nariz aún más alto, diciendo que ha hecho un código súper único en su cubo por sí mismo, sin la ayuda de miles de mentes anteriores, con una solución excepcional mejor que cualquier solución anterior. Verás - así es exactamente como colocará su cubo único con deslizadores...
ZS. Puede que haya hablado con dureza, pero tengo muy poca tolerancia con la estupidez impenetrable.
Cada uno de sus núcleos es una instancia de una clase en términos OOP. Y no importa cómo lo llames, es un elemento de OOP. Pero, por desgracia, este elemento se hace a sí mismo y cede en su poder conceptual a lo ya inventado y pulido por miles de mentes incompetentes.
Así es. Pero aún así, hay una diferencia significativa. Por lo que a mí respecta, en Peter's -en este ejemplo de clase- hay casi de todo. Y esto no encaja en el paradigma de encapsulación de la POO. Además, hay variables globales.
Así que aquí - sólo "elementos de OOP".
Pero, me temo que a la gente no le gustará lo contrario - estoy seguro, Vasily, de que cuando lance mi proyecto de POO, al contrario, la gente gritará que "no se puede hacer nada con esta interfaz, excepto para lo que está pensada" :)
Resulta que cada vez que se hace un nuevo gui, hay que hacer cambios en el motor (equiparlo con el núcleo GUI apropiado). Creo que es una solución fundamentalmente errónea. Imagine que hay cientos de usuarios de su motor. Pero el motor alojado en el Mercado o en otro lugar es sólo uno. ¿Cómo lo harás en este caso? ¿Para que cada usuario coloque un motor específico, que debe descargar por sí mismo? ¿Cómo se prepara el núcleo gui para el motor? ¿Proporcionará a cada usuario un motor individual? - Esto se convertirá rápidamente en una pesadilla. Así que su solución no es escalable.
No, Vasily, tiendes a dramatizar todo).
Hay un botón en el diseñador que, al pulsarlo, imprime todos los archivos.
Y el motor cargará los núcleos desde un archivo de texto. No es difícil de hacer.
Peter, realmente has entendido mal algo sobre la aplicación de la POO.
Es una forma especial de conciencia, no le impidas evolucionar