Una pregunta para los expertos en POO. - página 52
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
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.
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).
He aquí otro ejemplo:
Considere un sistema para mover una ventana con controles en un gráfico.
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).
Complicado. Injustificadamente complicado.
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...
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.
...
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.
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...
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.
...
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)).