¿Se demandará OOP en MQL5? - página 2
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
¿Qué le interesa, el proceso o el resultado final?)
Me interesan las dos cosas, pero el resultado final es algo más. ("... la POO te da muchas formas de ralentizar tus programas...")
No veo dónde la POO me permitiría escribir más rápido que con un enfoque procedimental, y eso compensaría todas las desventajas de la POO. Está claro quién lo necesita: el desarrollador que escribe para otros.
Permítanme hacer una analogía: el primero tomó un cuchillo y talló una figura de filigrana, mientras que el segundo se quitó medio dedo con el mismo cuchillo. ¿Qué sentido tiene esto? Cualquier herramienta puede servir para crear tanto una "golosina" como un vago total. Todo depende del programador, si es un artesano o tiene una chispa de talento. Esto es una digresión, pero en esencia - si usted prefiere FOP, a continuación, utilizarlo más.
Al crear el subjeto, quería ver argumentos a favor de la POO en proyectos con fines de MT. Tal vez debido a mi ignorancia -no estoy siendo coqueta- no los vi. Ahora tampoco los veo.
Permítanme resumir sus mensajes (gracias a todos, por cierto):
1. Comodidad y rapidez en la ejecución del proyecto.
2. Mantenimiento, mejoras.
3. El 5 es más rápido porque a quién le importa cómo programar.
3. La mano como razón de la lentitud de la OOP.
------------
(encogiéndose de hombros) Entienda que no estoy en contra de la POO, sólo quería averiguar por mí mismo lo que puede darme en tareas para la MT - en la creación de índices, scripts, Asesores Expertos.
DE ACUERDO. Hay una ayuda el día 5. ¿Quién puede dar un ejemplo de un simple indirecto de la norma MT4 escrito usando OOP en 5? Podrás ver allí. También puede estimar los retrasos a ojo del texto, la legibilidad del programa, etc.
1. La comodidad y la rapidez del proyecto.
2. Mantenimiento, mejoras.
1. La POO es muy conveniente para aquellos que entienden los principios básicos. Se nota incluso en las aplicaciones más sencillas. Cualquier aplicación es más conveniente de hacer con OOP.
2. El tamaño de un proyecto no es un obstáculo siempre que no sea difícil entenderlo. Y si un programa está orientado a objetos, no es muy difícil entenderlo. Un ejemplo es el terminal de SaxoBank. Está escrito en C#, que es un lenguaje orientado a objetos. Cada dll contiene unas 20 000 líneas de código. Si no fuera por la POO sería casi imposible entender tal cantidad de información, y más aún modernizarla.
Ya no tienen OOP en su núcleo (aunque la OOP absoluta es prácticamente inutilizable). Deberíamos haber creado clases abstractas desde el principio y utilizar la herencia y el polimorfismo para llegar a los objetos reales. Por ejemplo, para crear una clase base abstracta para indicadores personalizados con métodos y propiedades abstractas. Es mejor construir un árbol jerárquico de clases: un árbol para los objetos gráficos, para el trabajo con la cuenta, para los horarios y el acceso a las series temporales, etc. Y en el caso de los procedimientos y funciones predefinidos, sólo deben dejarse las rutinas elementales que requieran velocidad. Entonces podría ampliar las capacidades de la plataforma desde cualquier nivel de abstracción, lo que reduciría el tamaño del código y mejoraría su legibilidad y facilidad de comprensión para otros programadores. Y en MT5 ya se han implementado cosas bastante complejas a nivel de procedimientos (de hecho toda la plataforma está preparada para su uso) y no he visto la posibilidad de acceder por punteros al menos a los descriptores de las estructuras internas creadas, lo cual es muy limitante (a juzgar por la ayuda). En general, la necesidad de OOP es cuestionable, con una implementación de este tipo podríamos limitarnos a las estructuras y a la colocación dinámica. La programación orientada a la práctica debe estar apoyada desde abajo por una extensa jerarquía de clases .
Se necesitan de 1 a 3 años de programación para darse cuenta de que los programas NO ESCRITEN, sino que leen.
Se necesitan otros 1-2 años para darse cuenta de que los programas no se escriben para un ordenador, sino para un humano (en particular, para uno mismo).
Entonces se tarda 1-2 años en darse cuenta de que la POO y el C++ contradicen la forma de pensar y el método de construcción de lenguajes humanoides.
Se necesitan otros 1-2 años para estudiar el código de otras personas y darse cuenta de que los mejores y más fiables programas están escritos en Ce clásico.
Bueno después de eso basta con leer la entrevista de Dijkstra sobre que C++ y OOP le dan dolores de estómago.
Y después de eso (4-9 años en total) las preguntas "sobre OOP" no surgen en absoluto, y tales discusiones sólo causan una sonrisa indulgente.
Y después de eso (4-9 años en total) las preguntas sobre "OOP" no surgen en absoluto, y tales discusiones sólo evocan una sonrisa condescendiente.
>> Me solidarizo.