Mi enfoque. El núcleo es el motor. - página 135
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
Ahí hay un problema diferente. La limitación de los elementos y parámetros básicos. Sé cuál debe ser la solución. Pero aún no he tenido la oportunidad de hacerlo.
Por eso pregunto. Si tienes 21 cuerdas cosidas en el núcleo, no es muy bueno y no puedes arreglarlo.
No. Es código externo que se escribe para el constructor. Eso reproduce la tabla. Entonces hago clic en el botón y se imprimen todos los archivos de conexión y el núcleo de arranque del motor. Entonces todo funciona.
Según tengo entendido es un autogenerador que genera el código de autoconexión más parte del código del kernel. Esta es una solución interesante.
Todavía no lo he probado.
A mí me funciona. Pero parece que hay un problema con el cierre de una fila cuando se activa una parada. A veces la fila permanece. Se trata de un problema de detección de órdenes cerradas en el código que he escrito. La mesa no tiene nada que ver.
1. Por eso pregunto. Si tienes 21 líneas en el núcleo, no es bueno y no puedes arreglarlo.
2. Entiendo que es un autogenerador que genera el código de autoconexión más parte del código del núcleo. Una solución interesante.
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, ser ilimitada. La solución consiste únicamente 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 la interfaz se conectan al EA y comienzan a interactuar con él.
Para que no quede sin sustento, finalmente le daré un ejemplo del "núcleo" mismo. Más concretamente, se trata de un archivo de arranque. Hay varios núcleos.
Le recuerdo que se imprime automáticamente, basándose en el código KIB. Luego se coloca en el motor. Además, el motor funciona con él.
Nikolay, hablemos del tema. Por ejemplo, la clase CCanvas, de la que ya me he ocupado. Así que le quité todas las funciones. Los hizo independientes de la envoltura de la clase. ¿Cómo es que ahora es peor? Se hizo más fácil trabajar con ellos. He hecho una animación utilizando estas funciones. Antes de eso, apenas veía animaciones con esta clase.
Entonces, ¿por qué este envoltorio?
Tú también estás dibujando en un lienzo. Podrías llamar a una función específica y dibujar. Pero no. Envuelve y envuelve y envuelve. Entonces, explícame, ¿por qué?
Sí, porque es megacómodo. Pero es muy difícil de entender hasta que uno mismo empieza a utilizarlo.
No soy capaz de pensar de forma que me convenga. Por lo tanto, no es conveniente para mí. Envolver, representar la orientación del objeto. Clasificar cuando es necesario y no es necesario...
Uno tiene la impresión de que la propia OOP se antepone al mecanismo al que debe servir. Es decir, el mecanismo debe esforzarse por la integridad, por lo tanto por el menor número de sus bloques. Pero la POO obliga a estos bloques a multiplicarse por cualquier motivo. Como resultado, la estructura de los mecanismos está destrozada y no funcionan bien. Y se desarrollan aún peor.
Nikolay, empieza a crear megamecanismos (10 veces más grandes que la clase Kanvas), y entenderás dónde y cómo la POO se vuelve inconveniente.
No sé cómo pensar de una manera que me haga sentir cómodo. Por lo tanto, para mí, es incómodo. Envolviendo, retratando la orientación del objeto. Clasificar cuando es necesario y no es necesario...
Uno tiene la impresión de que la propia OOP se antepone al mecanismo al que debe servir. Es decir, el mecanismo debe esforzarse por la integridad, por lo tanto por el menor número de sus bloques. Pero la POO obliga a estos bloques a multiplicarse por cualquier motivo. Como resultado, la estructura de los mecanismos está destrozada y no funcionan bien. Y se desarrollan aún peor.
Nikolay, empieza a crear megamecanismos (10 veces más grandes que la clase Kanvas), y entenderás dónde y cómo la POO se vuelve inconveniente.
Tus palabras sólo dicen una cosa:
...
Nikolai, ¿se te ha ocurrido alguna vez que tu amor por la OOP no se justifica por casi nada más que por razones abstractas?
Digamos que, si estuvieras creando mecanismos gigantescos con esta OOP, estaría claro por qué la necesitas tanto. Justificarías específicamente por qué necesitas OOP. Pero, creas mecanismos relativamente pequeños. No hay suficiente código para sacar conclusiones sobre las desventajas y ventajas de uno u otro enfoque. Pero de todos modos sigues hablando de OOP. Mientras que la POO es sólo una herramienta, y no tiene sentido por sí misma. Es decir, si no hay ningún mecanismo que hacer, la OOP no es necesaria. Pero si hay un mecanismo, debería ser lo suficientemente serio como para requerir OOP al crearlo.
La mayoría de los que defienden la OOP no hacen nada serio. Sólo hacen cosas pequeñas. Sin embargo, su creencia en la POO es inquebrantable. Otros que hacen mecanismos mucho más serios son mucho menos propensos a gritar sobre la grandeza de la POO. Algunos incluso se manifiestan con críticas (ha habido un par de veces).
Por lo tanto, su argumento debe estar respaldado por la práctica, no sólo por la teoría. Yo, por ejemplo, puedo discutir sobre las ventajas de la POO en el desarrollo de la interfaz gráfica de usuario con Anatoly, porque podemos comparar las soluciones y sus matices en la práctica. Pero, contigo, no puedo desplegar mi argumento porque no lo entenderás. Lo harás, pero no lo entenderás (sin ánimo de ofender). Anatoly, por el contrario, puede entenderlo muy bien. La diferencia de experiencia en la creación de mecanismos globales es el principal motivo de malentendidos.
SZY. Como profesional te diré lo siguiente: el enfoque debe ser tal que maximice el potencial de los cerebros de un programador en particular. Yo mismo he encontrado un enfoque de este tipo.