PLO - página 7
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
En mi opinión, ¡estás muy equivocado!
Una vez que tengas proyectos grandes (al menos varios miles de líneas de código), verás que programar con clases (POO) hace muy fácil controlar el proceso de desarrollo y, sobre todo, el proceso de depuración.
Además, la POO hace que los proyectos se acerquen más a la vida real, de hecho en la vida real sólo tratamos con instancias de objetos (una casa, un árbol, un hombre, un coche, un pedido, etc.), es decir, con un conjunto de propiedades y métodos :)
Intenta hacer algo en OOP, verás que es más elegante y claro. Es más fácil que la programación procedimental.
MoneyJinn:
Utilice la programación procedimental habitual en MetaTrader 5.
La POO es una evolución de la programación procedimental.
Después de todo, nadie discute que se puede prescindir de las funciones. De hecho, es incluso más rápido, hasta cierto punto. No importa que haya fragmentos de código que realicen una misma acción con datos diferentes. Es muy fácil hacer una copia.
El uso repetido de funciones sale perdiendo frente a la POO. La ampliación de la funcionalidad es siempre la creación de una nueva función y el rediseño del código para que sea posible llamar a esta función dependiendo de diferentes condiciones. En un programa OOP correctamente escrito, una extensión es algo sencillo que no requiere rehacer todo el código.
Si al escribir programas sin POO no te sientes incómodo por los problemas de escalado, la abundancia de datos innecesarios y cientos de funciones, la superposición aleatoria de variables y la necesidad de "intercambio en caliente" de funcionalidad, no necesitas POO.
Sí, no hay que escribir en POO por el hecho de hacerlo, no saldrá nada bueno. No hay que sustituir las funciones por clases. Evitar los antipatrones
La OOP es un bicho, como "Niva" o "Lada".
Utilizar la programación procedimental habitual en MetaTrader 5.
Es tan accesible aquí como en MetaTrader 4.
Lástima que MetaQuotes no lo destaque.
La POO es una evolución de la programación procedimental.
Si al escribir programas sin POO no tienes molestias por problemas de escalado, abundancia de datos extra y cientos de funciones, superposición accidental de variables, necesidad de "intercambio en caliente" de funcionalidad, entonces no necesitas POO.
Sí, no hay que escribir en POO por el hecho de hacerlo, no saldrá nada bueno. No es necesario sustituir las funciones por clases.
Estoy de acuerdo al 100%.
Además, la POO hace que los proyectos se acerquen más a la vida real, porque en la vida real sólo tratamos con instancias de objetos (casa, árbol, persona, máquina, orden, etc.), es decir, con un conjunto de propiedades y métodos :)
¿Qué está más cerca de la realidad: una casa virtual, un árbol, una persona o ver el programa en la secuencia en que lo ejecuta el procesador?
Es una cuestión religiosa. Y cada uno tiene su propia elección.
Mi post era una respuesta a una pregunta de un topicstarter bloqueado que acabó pagando su aversión a la OOP,
Y también como una respuesta para los operadores comunes que tratan de dominar un producto como MT5 o cambiar a MT5 desde MT4.
Mi post era una respuesta a una pregunta de un tópico bloqueado que acabó pagando el precio de su aversión a la OOP,
Una lista de control para el iniciador del tema:
Laprogramación orientada a objetoses (léase la frase al revés) programación orientada a objetos. O la programación basada en objetos.
Por objeto se entiende el código de un programa (normalmente aislado de otro código), que describeparámetros y comportamiento de objetos reales (por ejemplo, "máquina") o ficticios (por ejemplo, "calabaza de grial"). Cada objeto puede tener una vida propia y cocerse en su propio jugo. Se utiliza un conjunto limitado de "canales nerviosos" para comunicarse con el mundo exterior - como funciones especiales con acceso externo.
En mi opinión, la principal ventaja de la POO es que el código objeto puede ser depurado independientemente de otro código. Y luego puedes montar, como un mosaico, objetos más complejos. Por ejemplo, un objeto "mujer" puede incluir otros objetos: "fuselaje", "tren de aterrizaje", "depósitos", "cabina", etc.
El Asistente MQL5 es un buen ejemplo de MQL OOP. Permite montar el Asesor Experto a partir de objetos ya preparados. Y estos objetos se pueden combinar.
El argumento más trágico a favor de la OOP: los que han entendido su esencia, se enganchan a ella. Es más fácil de programar; el código es más claro y estructurado.
...
El argumento más condenatorio a favor de la POO: los que la entienden se enganchan a ella. Simplemente es más fácil de programar, el código es más comprensible y más estructurado.
Eso es cierto, hasta que dominé la OOP me parecía que es una basura tan grande que ni siquiera vale la pena mezclarla.
Una vez que lo entendí, todo quedó claro, ya no necesito inventar nombres únicos para las variables,
No necesitas crear nombres únicos para las variables, no necesitas crear nombres únicos para los contadores i y j y no tienes que buscar en miles de códigos para encontrar donde esta variable no es nula. :o), y lo más importante, todo está delante de tus ojos - cuando abres el programa, todo está claro al instante, aquí está la llamada al objeto, aquí está la interacción de los objetos, si quieres entender lo que hace el objeto, vas al código del objeto ...
Eso es cierto, hasta que no dominé la OOP me parecía que era una chorrada tan grande que no merecía la pena ni meterse en ella.
En cuanto lo entendí, me deshice de todo, ya no necesito inventar nombres de variables únicos,
No necesitas crear nombres únicos para las variables, no necesitas crear nombres únicos para los contadores i y j y no tienes que buscar a través de miles de código para encontrar donde esta variable no es nula. :o), y lo más importante, todo es sencillo como la palma de la mano, cuando abres el programa, todo es inmediatamente comprensible, aquí está la llamada del objeto, aquí está la interacción de los objetos, si quieres entender lo que hace el objeto, vas al código del objeto
+10
Incluso discutiría la afirmación de que no se debe utilizar la POO para proyectos pequeños.
Me parece que la POO debe utilizarse siempre que sea posible: el código se alarga un poco, pero su transparencia aumenta muchas veces.
+10
Incluso me atrevería a discutir la tesis de que para los proyectos pequeños no es necesario utilizar la POO.
Me parece que la POO debe utilizarse siempre que sea posible: el código se alarga un poco, pero su transparencia aumenta muchas veces.
Soy partidario de la POO, ya que he comprendido la conveniencia de programar de abajo hacia arriba. De las interfaces de interacción de los objetos a la implementación de las clases. Todos los que empiezan con la implementación de clases no están escribiendo en POO adecuada, están escribiendo envoltorios funcionales. Estas envolturas no proporcionan más que un espacio de nombres conveniente para las variables y las funciones. Este es el enfoque habitual de las bibliotecas. Pero incluso este mínimo conviene a algunas personas y dicen con orgullo "escribo en OOP", lo cual es su derecho, sin embargo.
Hay programadores expertos y fundadores de corrientes enteras en el software moderno que tienen suficiente experiencia para criticar el paradigma de la POO. Este es un tema antiguo y, en principio, todo se ha discutido hasta el más mínimo detalle hace mucho tiempo, cuando y donde lo que se pierde:
http://blogerator.ru/page/oop_why-objects-have-failed
Esta es la respuesta de los partidarios de la OOP
http://bugtraq.ru/library/programming/objectshavenotfailed.html
Comparación de la velocidad de C++ (pequeña prueba) Programación orientada a objetos y procedimental (+ diferentes compiladores)
https://www.mql5.com/ru/forum/132434/page3