¿Qué puede hacer el código OOP que no pueda hacer el código procedimental?
La POO está diseñada para trabajar y pensar como los seres de la naturaleza, imaginemos que queremos desarrollar un juego de guerra donde tenemos vehículos de muchos tipos, soldados con muchas habilidades y armas con muchas especificaciones.
Desarrollar este tipo de juego sin POO será un dolor para el desarrollador para mantener un seguimiento de todos estos tipos de objetos y para gestionar las estructuras de datos y la memoria, y también para simular las características de POO como la herencia será difícil (aunque se puede hacer), POO hizo más fácil de pensar y desarrollar también más fácil de escribir, leer y depurar el código.
Algunas veces tener OOP más de lo necesario hará que la comprensión del código y la lectura sea poco amigable (mi punto de vista personal) que no me gusta
De hecho, no creo que pueda existir una tarea que no pueda ser refactorizada de código procedimental a OOP o viceversa. La diferencia está en la mantenibilidad y legibilidad del código. Por ejemplo, en el código procedimental se puede hacer referencia a datos globales y/o locales (variables). Además de éstas, la POO añade un ámbito más: las variables internas del objeto (estado). Es muy fácil y natural usarlas en POO, y la implementación procedimental de la misma lógica requeriría algún tipo de solución con código y estructuras de datos adicionales. En otras palabras, la POO es sólo una forma más corta y más agradable de codificación.
¿Cómo quieres construir una solución para las funciones virtuales sobrecargadas, incluyendo el árbol de herencia, que es la parte más importante de la POO? Parece que hablas de structs, no de POO.
OOP está diseñado para trabajar y pensar como los seres de la naturaleza , imaginemos si queremos desarrollar un juego de guerra donde tenemos vehículos con muchos tipos , soldados con muchas habilidades y armas con muchas especificaciones.
El desarrollo de este tipo de juego sin POO será un dolor para el desarrollador para realizar un seguimiento de todos estos tipos de objetos y para gestionar las estructuras de datos y la memoria bien, y también para simular las características de POO como la herencia será difícil (aunque se puede hacer), POO hizo más fácil de pensar y desarrollar también esier para escribir leer y depurar el código.
algunas veces tener OOP más de lo necesario hará que la comprensión del código y la lectura sea poco amigable (mi punto de vista personal) que no me gusta
Foro sobre comercio, sistemas de comercio automatizados y pruebas de estrategias de comercio
¿Qué puede hacer el código OOP que no puede hacer el código procedimental?
Alain Verleyen, 2016.05.22 14:03
Abro este tema con la esperanza de recoger información útil sobre las ventajas de la programación orientada a objetos frente a la programación procedimental.
Además, este tema es independiente del lenguaje, ya que mql4 y mql5 ofrecen el mismo lenguaje OOP (excepto algunas nuevas características avanzadas aún no disponibles en mql4 por el momento).
No quiero una "guerra" entre partidarios y detractores de la POO, así que este tema estará estrechamente moderado, no pierdas tu tiempo y el mío por favor.
Por favor, también proporcione ejemplos y código para ilustrar su punto, no alta teoría o conceptos abstractos.
EDIT: aunque este tema es independiente del lenguaje, todavía estamos hablando de comercio y mql4/mql5, así que nada de "juegos de guerra" o ejemplos de "manzanas y naranjas" por favor.
Soy un gran fan de la programación orientada a objetos (OOP) - no puedo ni imaginar que volvería al MQL procedimental. Es más fácil hacer programas más complejos. De todos modos... el problema con MQL es que un nuevo usuario lo tiene difícil para empezar aquí.
- Los métodos de eventos incorporados no son OO. Tienes que engancharte a ellos, lo que requiere la declaración de los objetos de escucha en el nivel raíz. Uno de los principios básicos de la POO se ve comprometido con este diseño.
- faltan paquetes de código "de sistema" con patrones comunes. Esto impide hacer paquetes compatibles entre usuarios, y un codificador serio de POO necesita mucho tiempo para crear los suyos privados. Los prefijos de nombres de clases no soportados (nombres de paquetes) son sólo un problema menor - cuando no se puede reutilizar el código externo de todos modos.
Así que no recomendaría empezar a aprender la POO justo en el MQL. El codificador necesita saber lo que necesita para que funcione.
La declaración "si... entonces... si no..." debería hacer el trabajo.
Eh, vamos ;) La verdad es que no ;) Si algo nativo podría hacer el trabajo de alguna manera extraña, entonces sus punteros, pero hay restricciones en MQL. Si entonces, de lo contrario ... el código se convertiría en absurdo. Y si aceptas el código absurdo como respuesta a la pregunta de este hilo, entonces es obsoleto en absoluto ;) ¿Estás de acuerdo en que el absurdo es una buena frontera? Vamos, di que sí, sólo una vez y sólo por mi ego ;)
Lo siento pero no voy a decir que sí... un código cumple su objetivo o no, si funciona de acuerdo con las especificaciones, no hay nada absurdo.
La pregunta es "¿qué puede hacer la POO que no pueda hacer la procedimental? Stanislav decía que la POO puede hacer lo mismo que la procedimental pero de forma "más corta y bonita". Estoy de acuerdo (excepto en lo de más corto, pero eso no es tan importante).
Programar GUIs fue lo que hice la mayor parte de mi tiempo como programador. No es posible codificar una GUI completa que necesite comunicarse en varias direcciones por medio de if then else. Necesitarías tantas declaraciones que el código se volvería ilegible y al final también demasiado lento lo que significaría: Objetivo no alcanzado, porque no quiero verme obligado a beber una taza de café después de cada clic hasta que vea el resultado.
Debido a la circunstancia de que una CPU no sabe nada de POO, se puede - por supuesto - codificar todo sin sólo usar punteros y matrices complejas. Pero eso es absurdo. También podría contratar a 10000 personas que dibujaran el contenido de mi pantalla en una película en tiempo casi real y lo proyectaran secuencialmente mediante un proyector de luz en la pared. ¿Es esto también alcanzar la meta?
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Usted acepta la política del sitio web y las condiciones de uso
Abro este tema con la esperanza de recoger información útil sobre las ventajas de la programación orientada a objetos frente a la programación procedimental.
Además, este tema es independiente del lenguaje, ya que mql4 y mql5 ofrecen el mismo lenguaje OOP (excepto algunas nuevas características avanzadas que aún no están disponibles en mql4 por el momento).
No quiero una "guerra" entre partidarios y detractores de la POO, así que este tema estará estrechamente moderado, no pierdas tu tiempo y el mío por favor.
Por favor, también proporcione ejemplos y código para ilustrar su punto, no alta teoría o conceptos abstractos.
EDIT: aunque este tema es independiente del lenguaje, seguimos hablando de comercio y mql4/mql5, así que nada de "juegos de guerra" o ejemplos de "manzanas y naranjas" por favor.