Mi enfoque. El núcleo es el motor. - página 135

 
Реter Konow:

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.

Reg Konow:

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.

 
Vasiliy Sokolov:

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.

 
Vasiliy Sokolov:

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.

Archivos adjuntos:
 
Реter Konow:

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 muy conveniente. Pero esto es muy difícil de entender hasta que uno mismo empieza a utilizarlo.
Y no es una envoltura en absoluto, sino un elemento multifuncional independiente, que no sólo es conveniente para usar en el editor debido a la visibilidad de su lista de propiedades y parámetros, sino también conveniente para editar y utilizar en otros programas como un módulo específico.
 
Nikolai Semko:
Sí, porque es megacómodo. Pero es muy difícil de entender hasta que uno mismo empieza a utilizarlo.
Y no se trata de un wrapper, sino de un elemento multifuncional independiente, que no sólo es cómodo de utilizar en el editor por la visibilidad de su lista de propiedades y parámetros, sino que también es cómodo de editar y utilizar en otros programas como un módulo específico.

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.

 
Реter Konow:

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:


 
Érase una vez un programador simpático, programaba para sí mismo, no conocía ninguna pena, era feliz, pero era un gran opositor a la OOP.
Los años pasaron, nuestro programador envejeció, y ahora siente que ha llegado su hora, así que llama a sus nietos y familiares y les dice:
- Tráeme un portátil, ¡haré una hoja de cálculo usando OOP!
Todos se sorprenden y dicen:
- ¿Cómo es posible que hayas estado trabajando en tu tableta toda la vida, sin una OOP. ¿Qué ha pasado?
Y el programador responde:
- Haré una hoja de cálculo con OOP, luego moriré y habrá un OOP menos.
 
Nikolai Semko:

...

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.

 
Реter Konow:


Si no publico nada grande no significa que no tenga nada grande. Es que sólo comparto las cosas pequeñas.
También me resistí al paradigma de la POO durante mucho tiempo, porque aprendí a programar cuando la POO aún no existía. Y la POO fue para mí una necesidad forzosa, cuando empezaba a empantanarme en el código procedimental de un gran proyecto. Y lamenté el tiempo perdido en la programación procedimental, cuando comprendí en la práctica todo el encanto y el poder de la POO.