¿Qué puede hacer el código OOP que no pueda hacer el código procedimental? - página 3
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 los proyectos a pequeña escala se puede demostrar que cualquier problema se puede descomponer en código de procedimiento. Sin embargo, las cosas se ponen mucho más difíciles cuando se tienen bases de código de varios millones de líneas con equipos de más de 100 desarrolladores, varios analistas de negocio y arquitectos que quieren hacer modificaciones al "modelo" de forma simultánea. En estas circunstancias, el modelo de "negocio" se define generalmente en una herramienta de diseño como UML y es accesible a todo el equipo.
Sólo el modelo de negocio contiene más de 5.000 clases. A partir de este modelo de negocio hay herramientas que "generan" clases para el modelo de objetos, las interfaces SQL y las capas de red, lo que eleva el número de clases a 15.000.
Para este debate, me gustaría desglosar el argumento del procedimiento frente a la programación orientada a objetos en tres "extensiones" que se han añadido al procedimiento desde la década de 1960/1970
1) "Basado en Objetos", donde los objetos y el código se encapsulan para crear "estructuras" avanzadas que también pueden tener comportamientos.
2) "Basado en clases": los objetos pueden heredar unos de otros y organizarse en jerarquías.
3) "orientado a objetos": el usuario puede definir comportamientos "polimórficos" (métodos virtuales o interfaces) dentro de las jerarquías de clases.
Hay un argumento que dice que todo lo anterior puede ser implementado en lenguajes procedimentales con suficiente esfuerzo, por ejemplo, la mayoría de los conjuntos de herramientas GUI en los 80/90 fueron creados en c y tenían estas características, pero no son fáciles de implementar por el codificador casual y no son realmente aplicables a esta discusión.
Así que para responder a la pregunta, ¿podemos implementar un proyecto de varios millones de líneas con más de 100 desarrolladores sin utilizar las 3 características de la POO?
Mi opinión personal es que es virtualmente imposible entregar un proyecto a gran escala sin 1) y 2) porque sin un sistema "basado en clases" es muy difícil mapear las estructuras de datos del mundo real y los comportamientos en el código de una manera limpia y concisa. Y más aún, a medida que el tamaño del proyecto aumenta, lo que comienza como un "podemos implementar eso en c" se convierte en una lista interminable de métodos con menos estructura que se vuelven más difíciles de mantener.
Ahora bien, los lenguajes que ofrecen sólo 1) y 2) no son lenguajes completamente OOP. Así que deberíamos considerar si los "métodos polimórficos (virtuales)" son realmente necesarios. Esto es un poco más de un "tal vez", o "a veces" porque el polimorfismo no es siempre la herramienta correcta para resolver un problema y puede complicar demasiado el diseño. Por ejemplo, cuando se modelan algunas estructuras de datos que se asignan a un almacén de objetos o a una base de datos SQL, la adición de comportamientos virtuales puede dificultar la asignación de datos; sin embargo, cuando se definen conjuntos de herramientas extensibles o API, el uso de una "interfaz" o una clase base con "métodos virtuales" es muy valioso. En general, soy un gran fan del polimorfismo cuando se utiliza con moderación y en el contexto adecuado.
He trabajado en algunas bases de código "C" de varios millones de líneas y en otras bases de código C++/Java/C# de varios millones de líneas, y la mayoría de las bases de código "C" entran en "modo de mantenimiento" después de 5 años porque los desarrolladores tienen miedo de cambiar la arquitectura, ya que el código es demasiado frágil y las modificaciones a menudo causan meses de doloroso redesarrollo y pruebas. En general, los proyectos orientados a objetos son mucho más resistentes a las modificaciones y a la refactorización.
La sentencia "if...then...else..." debería hacer el trabajo.
if...then...else no es capaz de codificar métodos "virtuales".
Hay varias implementaciones de "polimorfismo" en "C" y la mayoría de ellas utilizan vectores de punteros de función para mantener los mapeos necesarios. Más aún, estos "vectores de punteros de función" necesitan ser definidos para cada "tipo" que quieras modelar en la "jerarquía". Por supuesto, "C" no soporta jerarquías directamente, así que tendrás que resolver ese problema también.
Si realmente quieres entrar en la bolsa de gusanos que son los métodos "virtuales" implementados en "C" entonces puedes desenterrar los kits de herramientas de X Windows que están disponibles libremente en cada distribución de Linux.
Windows, por supuesto, tiene que ser ligeramente diferente y utiliza estructuras extensibles con identificadores de mensajes enteros, lo que significa que el comportamiento "polimórfico" se implementa a través de declaraciones de conmutación en los identificadores. (probablemente la forma más sucia de hacerlo, pero lo conseguirá)
¿Estás de acuerdo en que el sistema operativo Windows ofrece una buena interfaz gráfica de usuario? Que yo sepa está escrito en C. Lenguaje procedimental, no POO.
Te equivocas Dirk si crees que un programa complejo sólo puede construirse con POO. Más bien deberías explicar por qué es mejor codificarlo con POO.
El Kernel de Windows está en "C" pero el Kernel es sólo un pequeño componente de la base de código de Windows y gran parte de la base de código de nivel superior está implementada en C++ con interfaces externas de estilo "C" para soportar múltiples lenguajes.
Incluso los componentes de la interfaz gráfica de Windows implementan su propio "comportamiento polimórfico" que es efectivamente "OOP" implementado en "C". Por ejemplo, cuando recibes un "Handle" de un control de la interfaz gráfica de usuario, obtienes una estructura extensible en "C" con un comportamiento polimórfico disponible, esto es POO solo que envuelto en un feo conjunto de sintaxis en "C".
Decir que Windows no es POO porque está escrito en "C" no es del todo correcto.
No voy a construir una GUI en lenguaje procedimental para demostrar que estás equivocado. Pero podría hacerlo sin ninguna duda.
Por cierto, también es fácil codificar código ilegible y mucho más lento en POO, y como sabes la biblioteca estándar Metaquotes es una buena prueba de ello.
Que la POO sea mucho más lenta que el código procedimental es un completo mito. La razón por la que muchos proyectos de POO son más lentos es porque están mal diseñados. La sobrecarga de una llamada a una función virtual es mucho menor de lo que cabría esperar, especialmente con las arquitecturas actuales de obtención de memoria en chip que pueden buscar y ejecutar en paralelo.
https://hbfs.wordpress.com/2008/12/30/the-true-cost-of-calls/
Cita del enlace anterior: "Pero el coste de una llamada, sea cual sea el sabor, está dominado por la evaluación de sus argumentos. Hemos visto que las llamadas indirectas, ya sean de tipo C o métodos virtuales de C++, son inherentemente baratas. Una llamada a un método virtual no es más cara que una llamada indirecta utilizando un miembro de la estructura (algo->función(arg1,arg2)), por lo que considerar que una función virtual es increíblemente lenta está mal informado."
Java puede ser mucho más lento que C++ porque cada pieza de datos encapsulada debe ser en sí misma una clase basada en el heap, por lo que hay mucha más desreferenciación de objetos. Sin embargo, incluso Java puede ser exactamente igual de rápido que C en bucles y operaciones matemáticas básicas.
Si comparas C con C# es realmente muy difícil escribir un código que sea significativamente más rápido en C frente a C#, incluso cuando incluyes algunas de las características de POO.
Si la librería estándar de Metaquotes es lenta entonces será en un 90% debido al diseño de las características de la librería y tendrá muy poco que ver con las características de POO utilizadas.
(Como comparación, la biblioteca de plantillas estándar de C++ supera el 95% de cualquier proyecto de C que se haya escrito).
...
Gracias por su gran contribución.
Gracias por su gran contribución.
Gracias, y no me estaba burlando de ti, es que eres el único que defiende el argumento del procedimiento :)
No te preocupes, tengo que hacer mi papel de "moderador".
Claro, sería bueno ver algunos ejemplos de lo que sea que ustedes están hablando. La charla/escribir está muy bien para la gente que tiene experiencia en todo esto, pero yo soy un estudiante del tipo visual, por favor publiquen ejemplos.
Estoy en la valla en cuanto a si o no voy a seguir aprendiendo mql4, cambiar a mql5 o simplemente ir con otra plataforma.
Gracias Alain por iniciar este hilo. Este foro realmente necesita esto.
¿Realmente esperas que alguien profesional publique una librería compex, sin más, como "prueba"? ;) Podría poner un enlace a algo que no se puede vender en el mercado aquí, pero Alain me va a dar una patada si lo hago ;) Puedes visitar mi perfil y echar un vistazo a la foto del muro para hacerte una idea o enviarme un correo electrónico.
¿Otra plataforma? No encontrarás ninguna otra plataforma con un compilador tan potente. En absoluto.
@James Cater - muchas gracias por tus comentarios.
¿Realmente esperas que alguien profesional publique una librería compex, sin más, como "prueba"? ;) Podría poner un enlace a algo que no se puede vender en el mercado aquí, pero Alain me va a dar una patada si lo hago ;) Puedes visitar mi perfil y echar un vistazo a la foto del muro para hacerte una idea o enviarme un correo electrónico.
¿Otra plataforma? No encontrarás ninguna otra plataforma con un compilador tan potente. En absoluto.
@James Cater - muchas gracias por tus comentarios.