Preguntas sobre POO en MQL5 - página 55
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
Estás atrapado en las minucias. Poco interesante. El punto principal de la discusión del patrón "keeper" aquí fue que en cierto modo promete la preservación de la encapsulación, pero se implementa mediante la creación de un par de métodos públicos para cada campo. Es curioso que no hayas captado el mensaje más importante.
No estoy atascado, intento por respeto a ti como interlocutor dar sentido a tus palabras y desentrañar tus autocontradicciones. Aparentemente en vano.
Tampoco creo que a nadie de aquí le interese tu espuma de "patrones sagrados".
Aquí todo es claro, específico y canónico. Hay un libro. Este LIBRO expone estos patrones, y de eso estamos hablando. El libro se llama Design Patterns o algo así. Pero no sólo el libro, hay un montón de sitios sobre ellos en Internet e incluso en la Wikipedia, lo principal es que el tema está canonizado)) ...y quien no entiende los patrones de diseño - plebeyo, y quien los domina - ¡ha dominado la vida misma! ¡Amén!
Eres como un payaso, por desgracia. Simplemente deja el hilo de OOP, si te da tanto asco)
Aquí todo es claro, específico y canónico. Hay un libro. Este LIBRO expone estos patrones, y de eso estamos hablando. El libro se llama Design Patterns o algo así. Pero no sólo el libro, hay un montón de páginas web sobre ellos en Internet e incluso en la wikipedia, lo principal es que el tema está canonizado)).
Todo claro, si hay hasta 100 variables globales entonces podemos prescindir de las funciones, si hay más de 50 EAs entonces las clases son apropiadas, y entiendo correctamente, si hay más de 20 desarrolladores y más de 20 métodos y el número de variables es desconocido, entonces el patrón es necesario. Si sólo hay un desarrollador, entonces si es así, no tanto?
No estoy atascado, intento por respeto a ti como interlocutor dar sentido a tus palabras y desentrañar tus autocontradicciones. Aparentemente para nada.
Tampoco creo que a nadie de aquí le interese tu espuma de "patrones sagrados".
No tengo contradicciones, la contradicción está en tus patrones, ya he escrito sobre ellos dos veces, déjame recordarte: un patrón "keeper" promete la preservación de la encapsulación pero se implementa creando dos métodos públicos para cada campo privado.
Y dime, ¿dónde has visto una contradicción en mi patrón?
Por supuesto, si hay hasta 100 variables globales entonces podemos prescindir de las funciones, si hay más de 50 EAs entonces las clases son apropiadas, y entiendo correctamente, si hay más de 20 desarrolladores, más de 20 métodos y el número de variables es desconocido, entonces el patrón es necesario. Si sólo hay un desarrollador, entonces, si es así, no tanto?
Los desarrolladores necesitan cerebros en primer lugar.
Eres como un payaso, por desgracia. Simplemente deja el hilo de OOP si te da tanto asco)
¿Qué "eso"? Me gusta la OOP. Pero estos patrones notorios tienen una relación bastante lejana con la POO real.
No tengo ninguna contradicción, la contradicción está en sus patrones, ya he escrito sobre ellos dos veces, recordatorio: el patrón "keeper" promete preservar la encapsulación, pero se implementa creando dos métodos públicos por campo privado.
Ahora lo entiendo. Acabas de verter la emoción contra todos los patrones, que el significado de tus palabras se ha perdido.
Pero en Snapshot este problema se resuelve utilizando clases anidadas para Snapshot.
Si no está soportado por el lenguaje, estoy de acuerdo, existe ese inconveniente, pero se puede obviar con algunos trucos de muleta que recuerdo.
Ahora lo entiendo. Acabas de diluir la emoción contra todos los patrones, que el significado de tus palabras se perdió.
Pero en Snapshot este problema se resuelve utilizando clases anidadas para la instantánea.
Si no está soportado por el lenguaje, estoy de acuerdo, este inconveniente está presente, pero se puede obviar con algunos trucos de muleta, recuerdo.
Lo has entendido todo mal.
No importa si es posible escribir una clase anidada o no, no es una gran diferencia. Hay un ejemplo de código en este hilo con una clase anidada y dos métodos públicos por campo privado.
¿Qué "eso"? Me gusta la OOP. Pero estos patrones notorios tienen una relación bastante lejana con la POO real.
Lo diré de nuevo: nadie reza en los patrones. Se trata simplemente de patrones que pueden servir de referencia.
Pero afirmar que no tienen nada que ver con la OOP, bueno, eso no es cierto.
En mi humilde experiencia, en forma de libro puro, rara vez se utilizan, salvo raras excepciones. Por lo general, si hay una tarea adecuada para un patrón, va junto con al menos un par de otras tareas para otros patrones, y así es como cruzar 2-3-10+ patrones, esto es un trabajo para el cerebro del programador / arquitecto.
No entiendes nada.
No importa si puedes escribir una clase anidada o no, no es una gran diferencia. En este hilo hay un ejemplo de código con clase anidada y dos métodos públicos por campo privado.
Ya me has dicho tantas veces que soy un tonto y que no entiendo nada, que estoy orgulloso de mi compostura por no haberte mandado a la mierda merecidamente hace tiempo)
Básicamente - una clase anidada hace que los métodos públicos de los campos privados sean opcionales, esa es la violación de la encapsulación que estás escribiendo. ¿Algún otro argumento?