Preguntas sobre POO en MQL5 - página 50
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
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.
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?
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.
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))
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
o
No así:
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 )
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 ))))
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...