Preguntas sobre POO en MQL5 - página 50

 
Aleksey Mavrin:

Dimitri, en este caso probablemente estés confundiendo un poco los objetivos de los patrones Guardián y Prototipo, y todas sus posibles combinaciones y manifestaciones. En primer lugar, la instantánea no tiene que copiar necesariamente todo el objeto, a diferencia del prototipo.

Y sí, la necesidad de encapsulación aparece sobre todo en proyectos grandes con mucha gente. Para juguetes como la mayoría de estos, es un poco redundante.

De lo que se trata es de sentarse y hablar con toda seriedad sobre la asignación de un valor a una variable y luego utilizarla. Ah, sí, cuando se programa cualquier cosa sobre cualquier cosa, muchas veces se asignan diferentes valores a diferentes variables y luego se utilizan. Pero ahora se llama de otra manera, y ahora cuando se habla de ello, hay que fruncir las cejas y poner una mirada seria.

Y es importante no equivocarse, si todos los campos están guardados, es Prototipo, y si no todos, es Guardián, o los chicos se reirán.

 
Sergey Dzyublik:

No eres miembro de la secta "están instalando internet, no lo necesitamos, no necesitamos tu internet...", ¿verdad? ???


1. el custodio, por diseño, es similar al patrón que utilizan para almacenar el estado cuando escriben con contenido cambiante para revertir los cambios cuando estos no son uno sino varios cientos. Por ejemplo, editor de fotos, editor de texto...
Lo encontré después de escribir -https://refactoring.guru/ru/design-patterns/memento
2. Básicamente es una mala práctica no conocer y no entender el tema para criticar algo allí...
3. ¿Cómo es posible que algo que ya no entiendes se vuelva más confuso y difícil de entender?
4. El resto depende de ti...


¿Qué tiene que ver el GOP con esto?

 
Sergey Dzyublik:

Por casualidad, ¿no eres miembro de la secta "ellos instalan intinet, nosotros no lo necesitamos, tú intinet"? ???


1. el custodio, por diseño, es similar al patrón que utilizan para almacenar el estado cuando escriben con contenido cambiante para revertir los cambios cuando estos no son uno sino varios cientos. Por ejemplo, editor de fotos, editor de texto...
Lo encontré después de escribir -https://refactoring.guru/ru/design-patterns/memento
2. Básicamente es una mala práctica no conocer y no entender el tema para criticar algo allí...
3. ¿Cómo es posible que algo que ya no entiendes se vuelva más confuso y difícil de entender?
4. El resto depende de ti...


¡Estoy contigo hasta el final! Gracias por argumentar mi punto... Me daba mucha pereza))

Sólo añadiría en el punto 1 que la instantánea no almacena necesariamente todos los datos del objeto, y puede haber varias ramas con cientos de instantáneas del mismo objeto "instantáneas de diferentes lados". En ese caso, almacenar cientos de copias de datos no utilizados es realmente la peor práctica.

 
Dmitry Fedoseev:

Se ha llegado a esto: sentarse y hablar con toda seriedad sobre cómo se puede asignar un valor a una variable y luego utilizarla. Oh sí - cuando se programa cualquier cosa en cualquier cosa, muchas veces se asignan valores diferentes a diferentes variables, y luego se utilizan. Pero ahora se llama de otra manera, y ahora cuando se habla de ello, hay que fruncir las cejas y poner una mirada seria.

Y es importante no equivocarse, si se guardan todos los campos, entonces es el Prototipo, y si no todos, entonces el Guardián, o los chicos se reirán.

Dmitry, te aseguro que me encantaría reírme de ti, bueno, me encanta) pero en este caso, has exagerado, incluso particularmente bien sonreído.

Es que estás muy confundido, un SHOT no es igual a una COPIA DE OBJETO, te lo he señalado.

Si no está claro, déjame explicarte con un ejemplo: tienes 1000 bytes de objeto, necesitas 200 para la instantánea, así que por qué copiar 800, especialmente si tienes muchos millones de instantáneas guardadas.

p/s/ Y en general. La gente no se da cuenta de que los patrones son sólo un ejemplo elemental para resolver un problema elemental TÍPICO. Y de hecho las tareas no son elementales, sino más complicadas. Y para resolver problemas reales los patrones son necesarios, pero a menudo no en forma de libro puro, sino adaptados a una tarea particular, posiblemente combinados entre sí, posiblemente con la adición de alguna improvisación, expresada a veces en una simplificación, si la tarea lo permite, o viceversa "ponderación" de la realización.

De nuevo, por qué necesitas encapsulación e interfaces - esto probablemente no se puede entender si tu coeficiente intelectual está por debajo de Wasserman, o si no has participado en proyectos reales, cuando diferentes partes del proyecto son cambiadas por diferentes personas simultáneamente, y no seguir los principios básicos de OOPD implica enormes costes en la captura de bugs. Realmente, por qué todo esto para estampar EAs para el mercado))

 
Dada:
1. Una máquina de estado finito (FSA)
2. Se desconoce el número de KAs.
3. Estados de la nave espacial: exitosa / fallida / en funcionamiento
4. Las AC se ejecutan en varios hilos, el número de hilos es desconocido

Un patrón debe permitir:
1. Emitir un ID único para cada proceso - el contador no funciona
2. Añada el spa uniformemente por hilos
3. Obtener el estado de la nave espacial
4. Reinicia la KA si el estado de la KA es el mismo que el de la tarea emitida anteriormente
5. Guardar AC en la base de datos y eliminarlo del flujo si el estado es exitoso
6. Restaurar el estado de AC ( ID de guardar ) y añadirlo al flujo
7. Tener un pool común para el intercambio de mensajes de EA, el pool no es de goma, los EAs borrados no reciben mensajes, pero los EAs recién creados deben recibir los mensajes nuevos y no los dejados por los EAs muertos, no hay sincronización entre los hilos y los EAs
8. Guardar y restaurar el estado de todo el patrón y el grupo de mensajes

* Los KAs no realizan las mismas tareas
** El problema principal es el conjunto de mensajes, pero podría ser la CA o la DB o...
*** tal vez todo sea trabajo de base de datos y los patrones no son necesarios aquí en absoluto ?
 
?
 
Igor Makanu:
Dada:
1. Una máquina de estado finito (FSA)
2. Se desconoce el número de KAs.
3. Estados de la nave espacial: exitosa / fallida / en funcionamiento
4. Las AC se ejecutan en varios hilos, el número de hilos es desconocido

Un patrón debe permitir:
1. Emitir un ID único para cada proceso - el contador no funciona
2. Añada el spa uniformemente por hilos
3. Obtener el estado de la nave espacial
4. Reinicia la KA si el estado de la KA es el mismo que el de la tarea emitida anteriormente
5. Guardar AC en la base de datos y eliminarlo del flujo si el estado es exitoso
6. Restaurar el estado de AC ( ID de guardar ) y añadirlo al flujo
7. Tener un pool común para el intercambio de mensajes de los EAs, el pool no es de goma, los EAs borrados no reciben mensajes, pero los EAs recién creados deben recibir los nuevos mensajes y no los dejados por los EAs muertos, no hay sincronización entre los hilos y los EAs
8. Guardar y restaurar el estado de todo el patrón y el grupo de mensajes

* Las CA no realizan las mismas tareas
** El problema principal es el conjunto de mensajes, pero podría ser la CA o la DB o...
*** tal vez todo sea trabajo de base de datos y los patrones no son necesarios aquí en absoluto ?
1. Tienes una tarea compleja, por lo que la palabra patrón sólo puede usarse en plural en tu pregunta, si es que se usa :)
2. Hay que añadir CAs de manera uniforme en los hilos. ¿Qué hay de malo en una fábrica implementada con un idemaker singleton y un gestor de hilos? ¿Por qué un simple contador no es adecuado? ¿No puedes controlar la creación de CA o qué? Entonces, ¿estás haciendo un addon para el proyecto de otra persona o para el tuyo propio?
7. Observador con filtrado por tiempo de creación de la nave. Todas las implementaciones para MT.
Todo se guarda en la base de datos - la capa de la base de datos no es complicada.
Vinculación de las fábricas con la restauración de la base de datos sin dificultades.
Y en general - la respuesta correcta a su pregunta - necesita TODOS los patrones como mínimo. En serio. Después de dominarlas, todo lo que necesitas es emprender dichas tareas. Porque a lo largo del camino puedes necesitar tanto el decorador como la fachada (para la BD) y el visitante para implementar eventos de extremo a extremo y otros.

 

Sergey Dzyublik:

1. Un guardián, similar en diseño al patrón utilizado para almacenar el estado cuando se escribe con contenido cambiante para revertir los cambios cuando estos no son uno sino varios cientos. Por ejemplo, un editor de fotos, un editor de texto...

2. De hecho, es una mala práctica no conocer y no entender el tema para criticar algo allí...

Se ha destacado el punto clave. Es el contenido modificable la raíz de muchos problemas de mal uso de la POO. Yo también estuve en esto durante mucho tiempo, pero con la experiencia poco a poco se va entendiendo. El código en el que hay muchas interrelaciones entre objetos (punteros) y al mismo tiempo estos objetos son cambiables - es un fideo terrible que no cambiará. Por lo tanto, debemos esforzarnos por hacer que los objetos de referencia sean inmutables. Sólo los objetos de valor deben ser cambiables, es decir, las estructuras y los tipos simples, y los punteros también.

En este caso, es conveniente declarar el objeto inicial como una estructura, no como una clase. Entonces se puede cambiar su contenido. En este caso, por supuesto, no se tomará y guardará ningún puntero a él como en el patrón comentado, y esto es correcto. Para cambiar los objetos hay que referirse explícitamente a sus métodos, o pasarlos como argumento a una función, es decir

memento.restoreState(myObject);

o

myObject.restoreState(memento);

No así:

memento.restoreState();

parece que estamos cambiando un objeto memento, pero en realidad estamos cambiando algún otro objeto, que probablemente se encuentra en otra parte del programa. Esto crea un efecto secundario. Es lo mismo que cambiar una variable global en un lugar y usar su valor en otro lugar.

Es decir, un recuerdo no debe almacenar una referencia al objeto original. Sólo debe almacenar el contenido. Esta es mi opinión, pero creo que no estoy lejos de la verdad )

 
Aleksey Mavrin:
En general, la respuesta correcta a tu pregunta es que necesitas TODOS los patrones como mínimo. En serio.

No pretendo dar mi opinión, probablemente la haya leído en alguna parte, pero en mi opinión, sólo hay dos problemas en la programación: la estructura correcta del programa y encontrar rápidamente un buen nombre para una variable, y todo lo demás se hace con bastante facilidad

Yo también hablo en serio.

Gracias, voy a leer sus patrones

Esperaré, por si aparece alguien más, pero sólo a nivel de preguntas de principiante y entrenador akademvelopers swoop in ))))

 
Alexey Navoykov:

1)El código, que tiene muchas interrelaciones entre objetos (punteros), y al mismo tiempo los objetos son cambiables, es un fideo absurdo, en el que el diablo no puede entender después. Por lo tanto, hay que esforzarse para quelos objetos de referencia seaninalterables.
2)
Sólo los objetos-valor, es decir, las estructuras y los tipos simples, y los punteros deben ser cambiables.
3)
En este caso, esdeseable declarar el objeto inicial como una estructura, no como una clase. Entonces se puede cambiar su contenido. Por supuesto, no se puede tomar ningún puntero a él y guardarlo como en el patrón discutido, y esto es correcto.
4)Los objetos deben cambiarse llamando explícitamente a sus métodos o pasándolos como argumento a una función.
Parece queestamos cambiando el objeto memento pero en realidad se trata de algún otro objeto que probablemente se encuentre en otra parte del programa.Esto crea un efecto secundario.

1. Resulta que la estructura de datos Tree es todo del mal...
2. Pobre C++ donde class == private struct, qué hacer, probablemente deberíamos renunciar a las estructuras y a las clases.
3. Y así es: no hay patrones, no hay ordenación por punteros, no hay ahorro de memoria, especialmente para objetos grandes...
4. No debemos olvidar prohibir el uso de interfaces y funciones de plantilla, de lo contrario no entenderás con qué objeto estás trabajando, qué horror...