Una pregunta para los expertos en POO. - página 52

 

Miré a través de mi nuevo prisma, un híbrido de OOP y Kernel, los sistemas de objetos descritos en los programas, y casi me estalló el cerebro. En primer lugar, he echado un nuevo vistazo a mis sistemas GUI. A través de todos estos objetos-parámetros, objetos-estados, objetos-eventos y manejadores. Como la interfaz gráfica de usuario y su tecnología me resultan familiares, todo parecía bastante claro, pero el sistema es muy complejo. Una masa de parámetros, mapeos y manejadores. He llegado a la conclusión de que tales sistemas no pueden surgir por sí mismos. Y la selección natural no tiene poder aquí.

He aquí la razón:

Cada parámetro puede tener n número de parámetros derivados. Digamos: un cambio de X puede generar infinitos parámetros derivados de los valores de ese X en un momento dado.

Cada parámetro derivado debe tener un manejador y un enlace a otros parámetros. Ningún parámetro existe por sí mismo. El enlace es obligatorio.

El acoplamiento puede ser diferente y, en consecuencia, pueden aparecer diversos manipuladores -filtros, correctores, transductores-.

Los acontecimientos que pueden considerarse significativos para los sistemas son indefinidamente numerosos. Cada uno tiene sus propias propiedades, enlaces y manejadores. Las variaciones son innumerables.

Así, sin un concepto, no puede surgir ningún sistema. (Lo más probable).

Sólo no está claro cómo se originó la vida en la Tierra...

 

He aquí otro ejemplo:

Considere un sistema para mover una ventana con controles en un gráfico.

  • Tomamos dos parámetros - x e y - del objeto "cursor". A partir de ellos, crea dos objetos parámetro derivados que almacenarán la diferencia entre los valores actuales y pasados de x e y. (Los objetos parámetro no son sólo variables, son objetos con sus propias propiedades).
  • Creamos un Objeto Manejador para los Objetos Parámetros que (1)manejará los valores x e y, recuperando su diferencia entre los valores actuales y los pasados en el evento de manejo de la ventana, que se escribe en las propiedades del Manejador, (2)escribe la diferencia en los parámetros derivados en el mismo evento.
  • Cree un objeto de enlace entre los objetos de parámetros derivados y los objetos de parámetros x,y de cada objeto de ventana, que se utilizará para pasarles valores.
  • Después del Object-binder, creamos un objeto Handler más, que debe tomar el valor de los parámetros de objeto x e y de cada objeto ventana y añadirle un valor que va en el binder.

Así, con este sistema, podemos cambiar las coordenadas de una ventana y de sus objetos en el momento en que su asa es tomada por el cursor. Para moverlo todo, tenemos que asociarlo con las funciones del manejador ObjectSetInteger que cambian la posición del objeto MT en el gráfico.

Se trata de una implementación de una sola función de la interfaz gráfica de usuario mediante la vinculación de bloques especiales del sistema: parámetros de objetos, manejadores de objetos, etc.

Construir un sistema de este tipo en el Kernel, no es un poco más fácil (o quizás incluso más difícil) que escribir código normal sin convertir todo en un Objeto. Pero, seguiré investigando...


ZS. Se me olvidó añadir que para mover la ventana, también necesitamos "fabricar" un Objeto de Evento, que bloquea el tirador de la ventana y el movimiento del cursor. Y este objeto de evento, conectarlo al objeto manejador de los valores x,y del cursor (que escribe la diferencia en los parámetros derivados), y funcionaría sólo en la señal de este evento.

Y para cada objeto de evento, necesitas crear un manejador de objeto y vincularlo a él.

Cada manejador de objetos tiene sus propias propiedades, y sus valores son utilizados por él cuando trabaja con parámetros o eventos. Por lo tanto, debe haber una plantilla, o te empantanarás creándolo todo).

 
Реter Konow:

He aquí otro ejemplo:

Considere un sistema para mover una ventana con controles en un gráfico.

  • Tomamos dos parámetros - x e y - del objeto "cursor". A partir de ellos, crea dos objetos parámetro derivados que almacenarán la diferencia entre los valores actuales y pasados de x e y. (Los objetos parámetro no son sólo variables, son objetos con sus propias propiedades).
  • Creamos un Objeto Manejador para los Objetos Parámetros que (1)manejará los valores x e y, recuperando su diferencia entre los valores actuales y los pasados en el evento de manejo de la ventana, que se escribe en las propiedades del Manejador, (2)escribe la diferencia en los parámetros derivados en el mismo evento.
  • Cree un objeto de enlace entre los objetos de parámetros derivados y los objetos de parámetros x,y de cada objeto de ventana, que se utilizará para pasarles valores.
  • Después del Object-binder, creamos un objeto Handler más, que debe tomar el valor de los parámetros de objeto x e y de cada objeto ventana y añadirle un valor que va en el binder.

Así, con este sistema, podemos cambiar las coordenadas de una ventana y de sus objetos en el momento en que su asa es agarrada por el cursor. Para moverlo todo, tenemos que asociarlo con las funciones del manejador ObjectSetInteger que cambian la posición del objeto MT en el gráfico.

Se trata de una implementación de una sola función de la interfaz gráfica de usuario mediante la vinculación de bloques especiales del sistema: parámetros de objetos, manejadores de objetos, etc.

Construir un sistema de este tipo en el Kernel, no es un poco más fácil (o tal vez incluso más difícil) que escribir código normal sin convertir todo en un Objeto. Pero, seguiré investigando...


ZS. Se me olvidó añadir que para mover la ventana, también necesitamos "fabricar" un Objeto de Evento, que bloquee el manejador de la ventana y el movimiento del cursor. Y este objeto de evento, conectarlo al objeto manejador de los valores x,y del cursor (que escribe la diferencia en los parámetros derivados), y funcionaría sólo en la señal de este evento.

Y para cada objeto de evento, necesitas crear un manejador de objeto y vincularlo a él.

Cada manejador de objetos tiene sus propias propiedades, y sus valores son utilizados por él cuando trabaja con parámetros o eventos. Por lo tanto, debe haber una plantilla, o te empantanarás creando todo esto).

Difícil. Injustificadamente difícil.
El objeto principal de una forma, dentro del cual se encuentran otros objetos de esta forma, es el único que recibe coordenadas. El cambio de cualquier coordenada modifica la posición del objeto principal del formulario. A los demás objetos de ese formulario se les pasan simplemente coordenadas relativas que determinan su ubicación dentro del formulario. Todos los objetos tienen su propio orden en el formulario, y se reorganizan en ese orden. Cada objeto tiene una lista de lo que contiene en su interior. La referencia a la lista de contenidos permite dar a cada contenido una orden de desplazamiento. Así, al dar una orden de desplazamiento al objeto formulario, se pasa automáticamente la cadena para desplazar todo el contenido del formulario. Es decir, sólo se compensa la forma, y todo lo demás se compensa automáticamente. No tenemos que dar a cada objeto de formulario un comando de desplazamiento por sí mismo.
Lo hacemos para un solo objeto. Todos los demás lo repetirán. No importa lo complejo que sea un objeto de formulario, un solo comando de desplazamiento se pasará a todo el contenido de ese formulario en una avalancha.
Todo se hace una sola vez. Y entonces todo se hará en cadena.
 
Artyom Trishkin:
Complicado. Injustificadamente complicado.
El objeto principal de una forma, dentro del cual se encuentran los demás objetos de esa forma, es el único que recibe coordenadas. El cambio de cualquier coordenada modifica la posición del objeto principal del formulario. A los demás objetos del formulario se les pasan simplemente coordenadas relativas que determinan su posición dentro del formulario. Todos los objetos tienen su propio orden en el formulario, y se reorganizan en ese orden. Cada objeto tiene una lista de lo que contiene en su interior. La referencia a la lista de contenidos permite comandar cada contenido a un desplazamiento. Así, al dar una orden de desplazamiento al objeto formulario, se pasa automáticamente la cadena para desplazar todo el contenido del formulario. Es decir, sólo se compensa la forma, y todo lo demás se compensa automáticamente. No tenemos que dar a cada objeto de formulario un comando de desplazamiento por sí mismo.
Hacemos esto para un solo objeto. Todos los demás lo repetirán. No importa lo complejo que sea un objeto de formulario, una sola orden de desplazamiento pasará a todo el contenido de ese formulario en una avalancha.
Todo se hace una sola vez. Y entonces todo se hará en cadena.

Así es.

El enlace entre los parámetros derivados que contienen la diferencia x,y del cursor y los objetos de formulario (que están en la cadena) tiene un manejador en el centro que puede realizar una conexión en serie con los parámetros x,y de cada objeto de formulario. Es decir, la vinculación de los parámetros a través del manejador de conexión en serie permite reemplazar la vinculación de cada objeto de formulario con parámetros derivados que pasan valores de diferencia x,y. Yo también estaba pensando en ello.

En mi GUI, el movimiento de la ventana se implementa dentro de la función haciendo lo siguiente:

(1) Comprobador de eventos para el evento de clic de la manija de la ventana

(2) Evento de mover el cursor

(3) Calcular la diferencia entre las coordenadas actuales del cursor y las coordenadas pasadas del cursor

(4) Recorrer los objetos de la ventana y cambiar sus coordenadas ajustando la diferencia de posición del cursor.

(5) Llamar al ObjectSetInteger para mover el objeto МТ de la forma de la ventana (lienzo) a lo largo del gráfico por la distancia dada.


Por lo tanto, la implementación dentro de la función es correcta. La implementación a través de los Manejadores de Objetos, Parámetros de Objetos y Vinculaciones de Objetos se ve torpe contra este fondo. Pero, profundicemos...

 
Реter Konow:

Esto es correcto.

El mapeo entre los parámetros derivados que contienen la diferencia x,y del cursor y los objetos formulario (que están en la cadena) tiene un manejador en el medio que puede realizar una conexión en serie con los parámetros x,y de cada objeto formulario. Es decir, la vinculación de los parámetros a través del manejador de conexión en serie permite reemplazar la vinculación de cada objeto de formulario con parámetros derivados que pasan valores de diferencia x,y. Yo también estaba pensando en ello.

En mi GUI, el movimiento de la ventana se implementa dentro de la función haciendo lo siguiente:

(1) Comprobador de eventos para el evento de clic de la manija de la ventana

(2) Evento de mover el cursor

(3) Calcular la diferencia entre las coordenadas actuales del cursor y las coordenadas pasadas del cursor

(4) Recorrer los objetos de la ventana y cambiar sus coordenadas ajustando la diferencia de posición del cursor.

(5) Llamar al ObjectSetInteger para mover el objeto МТ de la forma de la ventana (lienzo) a lo largo del gráfico por la distancia dada.


Por lo tanto, la implementación dentro de la función es correcta. La implementación a través de los Manejadores de Objetos, Parámetros de Objetos y Enlaces de Objetos se ve torpe contra este fondo. Pero, profundicemos...

Sí, porque no es necesario que estos manejadores estén separados del objeto. La clase que devuelve las coordenadas del cursor puede hacerse estática - estará disponible para cualquier clase en el programa, y obtener las coordenadas y responder a ellas debe ser implementado en cada objeto. Pero sólo el objeto formulario principal debe llamar a estos manejadores. Entonces, para todos los demás objetos de formulario es suficiente con especificar las nuevas coordenadas y volver a dibujar. Dentro del objeto formulario hay una lista de todos sus objetos. El objeto formulario ha definido el cambio de sus coordenadas - establece nuevos valores a sus coordenadas, recorre su lista de objetos y llama a los métodos para establecer las coordenadas de cada objeto de su lista. Al mismo tiempo, cada objeto posterior hace lo mismo cuando sus coordenadas cambian: busca en su lista de objetos y les ordena que cambien sus coordenadas. Los objetos de las listas están dispuestos en el orden en que se dibujan (secuencia Z). En otras palabras, cada objeto tiene su propio método de cambio de coordenadas, pero se implementa de la misma manera - busca en la lista de todos los objetos "amigos" y llama al mismo método para cada uno de ellos. Así, llamando a este método una vez para el objeto principal del formulario, iniciamos automáticamente un cambio de coordenadas para todos los objetos del formulario. Cuando la lista de objetos "amigos" del objeto formulario ha sido procesada, llama a su método de redibujado del gráfico, que es el mismo para todos los objetos modificados.

 
Artyom Trishkin:

...

Esta es la vista estándar OOP del mecanismo de movimiento de la ventana. Te mostraré una diferente. Para ello, despeja tu mente por un segundo y sigue mi pensamiento.

  1. Imagínate una matriz de array. Las dimensiones son indefinidas. Quizás sea infinito, quizás no. No importa.
  2. La matriz se inicializa con ceros. Los ceros representan el vacío. Es decir, la matriz está vacía.
  3. En el vacío de la matriz ha aparecido algo distinto al vacío. Es un cero sustituido por un valor. No importa lo que sea.
  4. Vemos este valor en la matriz vacía y decimos "esto es un parámetro". Es decir, no el valor en sí, sino la celda en la que apareció. La celda se honra con el título y se llama parámetro, es decir, la "capacidad" que contiene el valor.
  5. El parámetro nos exige inmediatamente su definición. Es como si dijera "¡Soy un parámetro y tengo personalidad! ¿Dónde están mis propiedades?". Y no tenemos más remedio que añadir al parámetro sus propiedades, que también son parámetros con sus propios valores. Los ponemos al lado y tenemos una cadena: un parámetro y sus propiedades. Decimos "¡creamos un objeto-parámetro!".
  6. A continuación, el parámetro "dice": "¿Dónde están los otros parámetros? ¿Por qué soy el único?" Y luego creamos algunos parámetros más en el vacío de la matriz, para que el "primogénito" no se aburra. Por supuesto, cada uno de los nuevos parámetros declara su individualidad y exige propiedades como sus portadores. Así crecen las cadenas de parámetros, entre los que se encuentran los "primogénitos" y sus propiedades. Decimos "¡Hemos creado Objetos Paramétricos!".
  7. Ahora en el vacío de la matriz tenemos varios parámetros con cadenas de sus propiedades. Pero cada uno de ellos "grita" sobre el sinsentido de su existencia. Cada uno de ellos está solo. Entonces, decidimos vincular los parámetros para que no se "aburran". Para ello, creamos parámetros especiales que sirven de enlace entre otros parámetros. También están formados por cadenas de propiedades. Ahora, los parámetros primogénitos están vinculados entre sí mediante el encadenamiento de parámetros. Todo el mundo está contento. Decimos: "¡Hemos creado objetos de unión de parámetros!".
  8. Pero, entonces resulta que los primarios de los parámetros quieren comunicarse y transferir valores entre sí a través de los enlaces, pero los enlaces proporcionan la transferencia de valores (lenguaje de los parámetros), pero no proporcionan la traducción. Y al estar solos, los parámetros sólo entienden su lenguaje, lo que significa que hay una "barrera lingüística" entre los parámetros y requieren que la resolvamos.
  9. Para resolver el problema de la "comunicación de parámetros" no teníamos suficientes mapeos, necesitábamos una traducción. Esto significa que los valores pasados entre los parámetros deben ser convertidos, teniendo en cuenta las propiedades de cada parámetro. Algunos de ellos comprenden valores en el rango 1-10; otros entienden (-5) - (-105). Algunos operan con números fraccionarios, otros con potencias. Por lo tanto, llegamos a la conclusión de que necesitamos "traductores", es decir, manejadores de valores que tengan en cuenta las propiedades de los parámetros. Creamos Objetos Manejadores especiales y los insertamos en mapeos de parámetros. Los objetos manejadores de valores "traducen" los valores pasados entre los parámetros utilizando las propiedades de los parámetros que pasan y reciben, y sus propias propiedades. Decimos: "¡Hemos creado objetos manejadores! Ahora los parámetros pueden comunicarse libremente".
  10. Los parámetros del primogénito se comunicaban y comunicaban y se cansaron de ello. Cansado de ello. Entonces decidieron que sólo se comunicarían en ocasiones especiales, es decir, cuando uno de ellos obtuviera un valor increíble. Pero, al final, tuvimos que estar atentos al valor, como un niño, sin cansancio. Los parámetros del primogénito nos pidieron que pensáramos en un "sistema de vigilancia" que señalara las variaciones inusuales para que no se preocuparan. Así que hicimos un molde de los valores a los que debíamos reaccionar y le añadimos un manejador especial, que dio lugar a un "objeto de evento". Lo conectamos a cada parámetro y comienzan a comunicarse entre sí utilizando señales de los objetos de eventos. Así pues, creamos "Objetos-Evento".

Ese es el final del cuento...

Miramos la matriz desde fuera y nos quedamos boquiabiertos. "¡Hemos creado un sistema de objetos!")

ZS. Obsérvese que todo puede crearse en una matriz-array. Y la matriz es el núcleo. Y las entidades en él - los objetos reales. Y parámetros, y eventos, y enlaces, y propiedades, y manejadores. Hay incontables sistemas que se pueden construir en el Núcleo a partir de estas cosas de base.

 

Un simulacro de continuación...

11. De alguna manera, los parámetros del primogénito decidieron seguir una moda. Descubrieron que hay una feria de propiedades en algún lugar de la matriz, y un cierto espacio en la novedad. Dicen que tiene tres propiedades. "Dimensiones" se llaman. Estas propiedades tienen un rango supuestamente infinito de valores, y como extra regalan otro "parámetro-tiempo". Los parámetros llegaron a la feria y tomaron las propiedades x,y,x_size,y_size. Dicen que quieren hacer una concha en el espacio. Y tomaron color. Volvieron y empezaron a vestir las nuevas propiedades. Modelaron y modelaron algunas envolventes espaciales hasta que se cansaron. Crecieron inmensamente, luego se derrumbaron... Luego se pusieron colores y se relajaron. Empezaron a pensar qué hacer a continuación. Y luego miraron la caja de propiedades del tiempo. Veamos qué es... Lo abrieron, lo unieron a sí mismos, pero no calcularon los valores y en un momento se evaporó en el vacío. Al fin y al cabo, el tiempo es un parámetro con el que hay que tener mucho cuidado...

 
Реter Konow:

Un simulacro de continuación...

11. De alguna manera, los parámetros del primogénito decidieron seguir una moda. Descubrieron que hay una feria de propiedades en algún lugar de la matriz, y un cierto espacio en la novedad. Dicen que tiene tres propiedades. "Dimensiones" se llaman. Estas propiedades tienen un rango supuestamente infinito de valores, y como extra regalan otro "parámetro-tiempo". Los parámetros llegaron a la feria y tomaron las propiedades x,y,x_size,y_size. Dicen que quieren hacer una concha en el espacio. Y tomaron color. Volvieron y empezaron a vestir las nuevas propiedades. Modelaron y modelaron algunas envolventes espaciales hasta que se cansaron. Crecieron inmensamente, luego se derrumbaron... Luego se pusieron colores y se relajaron. Empezaron a pensar qué hacer a continuación. Y luego miraron la caja de propiedades del tiempo. Veamos qué es... Lo abrieron, lo unieron a sí mismos, pero no calcularon los valores y en un momento se evaporó en el vacío. Al fin y al cabo, el tiempo es un parámetro con el que hay que tener mucho cuidado...

¿Y los diez primeros no eran serios?

Yo, por mi parte, no puedo leer sin reírme.

 
Artyom Trishkin:

...

Toda esta "objetividad" es muy confusa, ¿no te parece? Hay que tener cuidado con él. Nikolai Semko tenía razón sobre la proximidad del genio y la esquizofrenia. Es posible "volverse loco". Hay cosas que es mejor no entender. Algunas puertas, deben estar siempre cerradas a nuestra Conciencia. Como decía una película, - "el parásito más peligroso es una idea. Una vez en el cerebro, es imposible sacarlo". La matriz de la que hablaba es peligrosa para la mente. Es fácil perderse en ella y perderse para siempre. Seamos cuidadosos)).

 
La representación de los sistemas en Matrix ofrece una nueva perspectiva de sus estructuras, pero no vi ningún indicio de que se facilite la creación de sistemas. Por no hablar de cualquier "autodesarrollo". Es condenadamente interesante ver los sistemas de esa manera, pero no más que eso. No veo ningún tipo de autodesarrollo, ni siquiera un indicio de ello. Por lo tanto, dejemos lo divino a Dios. No se puede lograr el autodesarrollo de sistemas ni con el enfoque OOP estándar, ni con el mío.