Preguntas sobre POO en MQL5 - página 49
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
¿Y el objetivo de estos juegos mentales salvajes? El "propósito" (entre comillas, porque... gladiolo) del patrón es"sin romper la encapsulación, fijar y preservar el estado interno del objeto" (entre comillas, porque entre comillas). Pero no se puede prescindir del método setState(). Entonces, ¿dónde está el ahorro de la encapsulación aquí? Para escribir dos métodos más para cada campo privado... Sí... genial, el encapsulado se conserva.
Y sé sincero, ¿utilizarás este enfoque en la práctica? Lo dudo. En la práctica, lo hará de forma explícita y transparente: por ejemplo, una estructura con el mismo conjunto de campos y un par de métodos para guardar y restaurar. Y entonces la encapsulación se conservará realmente, sólo habrá dos nuevos métodos: para guardar el estado y para restaurar.
OK, lo guardaré, necesitaba probar el principio de trabajo, tal vez esto es lo que estaba buscando - un código para el probador y para el EA de trabajo, que puede guardar su estado, y en el probador por el contrario no gastar recursos en "gestos extra" - parte de tal patrón puede ser cubierto por #ifdef -ami ;)
Estoy tratando de entender el significado de este crammer con el keeper, pero no le veo ninguna utilidad en particular. De hecho, es una mala práctica de programación por la creación de efectos secundarios. Cuando cambias un objeto cambias otro. Como resultado, el código se vuelve enmarañado y difícil de entender. Es mejor esforzarse por la pureza del código, en mi opinión.
¿Qué le impide simplemente copiar un objeto en otro objeto y luego volver a copiarlo? Es esencialmente lo mismo, sólo que más correcto y más claro.
Si este singleton tiene setters y getters al mismo tiempo (es decir, permite cambiar su estado y leerlo), equivale a trabajar con variables globales. Y todo programador sabe que trabajar cambiando el estado global es malo. Pero el singleton de alguna manera no cuenta )
Estoy tratando de entender el significado de esto de la custodia, pero no veo ningún beneficio en particular. De hecho, es una mala práctica de programación al crear efectos secundarios. Cuando se cambia un objeto, se cambia otro. Como resultado, el código se vuelve enmarañado y difícil de entender. Es mejor esforzarse por la pureza del código, en mi opinión.
Es más sencillo, estoy aprendiendo la parte técnica
Estoy acostumbrado a evaluar el estado de un sistema automatizado desde el punto de vista de una máquina de estado finito, y siempre quiero tener la oportunidad de mantener una "instantánea" del estado del sistema como reserva ))))
Estoy más acostumbrado a evaluar el estado de un sistema automatizado desde la perspectiva de una máquina de estado finito, y esto siempre me hace querer guardar un "molde" del estado del sistema como respaldo )))
Lo que ocurre es que, en mi opinión, esa aplicación es demasiado complicada y confusa.
El objetivo es claro, sólo que es demasiado complicado y confuso, en mi opinión.
Por desgracia, la gente es así, hasta que no tenga mis patadas y golpes en el culo, es poco probable que lo consiga))
Por desgracia, la gente es así: hasta que no reciba mis propios golpes, es poco probable que lo consiga))
No hay nada de malo en que alguien estudie estos patrones, es genial - es una gimnasia para el cerebro, etc. etc. Y luego, al examinarlo más de cerca, resulta que es una especie de falsificación infernal, una especie de meme para alejar a los bobos de la realidad, al igual que aprender BASIC visual escribiendo aplicaciones de consola.
El estudio de estos patrones es interesante, aunque sólo sea desde el punto de vista del aprendizaje de las cucarachas de alguien: lo que son en la naturaleza.
Y si realmente estamos abordando la tarea de preservar el estado de un objeto, el camino es hacer posible la copia de un objeto a otro, lo que uno quiera, ya sea un simple método o una sobrecarga = overloading. Y después de eso, es posible que no quieras encapsular esta característica.
Y si realmente abordamos la tarea de preservar el estado de un objeto, la forma de hacerlo es hacer posible la copia de un objeto a otro, lo que uno quiera, ya sea sólo a través de un método o a través de una sobrecarga =. Y después de eso, es posible que no quieras encapsular esta característica.
En realidad, cualquier sistema técnico puede diseñarse a partir de 3 principios básicos:
- se ajusta a la norma más reciente
- nuestros abuelos lo construyeron así, no hace falta reinventar la rueda
- No deberías construirlo con mierda y palos y luego modificarlo
)))
Es broma, tengo tiempo para leer y jugar con las opciones, lo aprovecho, así como la oportunidad de obtener una explicación rápida de los puntos poco claros en el foro ;)
Estoy tratando de entender el significado de esto de la custodia, pero no veo ningún beneficio en particular. De hecho, es una mala práctica de programación al crear efectos secundarios. Cuando se cambia un objeto, se cambia otro. Como resultado, el código se vuelve enmarañado y difícil de entender. Es mejor esforzarse por la pureza del código, en mi opinión.
¿Qué te impide simplemente copiar un objeto en otro objeto y luego volver a copiarlo? Es prácticamente lo mismo pero más correcto y claro.
Si este singleton tiene setters y getters al mismo tiempo (es decir, permite cambiar su estado y leerlo), equivale a manejar variables globales. Y todo programador sabe que trabajar cambiando el estado global es malo. Pero el singleton de alguna manera no cuenta )
Supongo que es el típico punto de vista de un programador que nunca ha tenido nada que ver con proyectos serios de gran envergadura... Perdonadme por ser tan directo, pero no veo otra explicación para llamar a lo básico mala práctica )
No hay nada de malo en que alguien estudie estos patrones, es genial - ejercicios cerebrales, etc. etc. Y luego, al examinarlo más de cerca, resulta ser una especie de falsificación infernal, una especie de meme para atraer a los bobos lejos de la realidad, al igual que aprender BASIC visual escribiendo aplicaciones de consola.
El estudio de estos patrones es interesante, aunque sólo sea desde el punto de vista del aprendizaje de las cucarachas de alguien: lo que son en la naturaleza.
Y si realmente estamos abordando la tarea de preservar el estado de un objeto, el camino es hacer posible la copia de un objeto a otro, lo que uno quiera, ya sea un simple método o una sobrecarga = overloading. Y más allá de eso, tal vez el deseo de encapsular esta característica desaparezca.
Dmitry, probablemente en este caso confundes un poco las tareas de los patrones Keeper y Prototype, y todas sus posibles combinaciones y manifestaciones. La primera 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 estas tareas aquí, es exagerado, por supuesto)
1) Estoy tratando de entender el sentido de esto del custodio, pero no veo el beneficio.
2) Es esencialmente una mala práctica de programación crear efectos secundarios.
3) Cuando cambias un objeto, cambias otro. El resultado es que el código se vuelve enmarañado y difícil de entender. Aún así, es mejor esforzarse por la pureza del código, en mi opinión.
4) ¿Qué te impide simplemente copiar un objeto en otro objeto y luego volver a copiarlo? En esencia es lo mismo pero más correcto y claro.
Si este singleton tiene setters y getters al mismo tiempo (es decir, permite cambiar su estado y leerlo), es equivalente a trabajar con variables globales. Todo programador sabe que trabajar cambiando el estado global es malo. Pero el singleton de alguna manera no cuenta )
¿No formas parte de la secta "ellos lo instalan, nosotros no lo necesitamos, es tuyo..."? ???
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...