Presentación

EL PARADIGMA DE LA PROGRAMACIÓN ORIENTADA A OBJETOS, DIFICULTADES DE IMPLANTACIÓN.
En mis años de experiencia, primero como programador  y como analista después. He trabajado y analizado multitud de proyectos informáticos,  pero en pocos por no decir ninguno, he observado un diseño adecuado del proyecto.
En la mayoría he visto como no hay ningún diseño, los programadores tiran código con la esperanza de que funcione, pero cuando hago un análisis inverso de como está hecho el proyecto, para mi sorpresa siempre encuentro varias decenas de clases sin ningún tipo de interconexión entre ellas.
Incluso en los proyectos más rígidos en los que hay una normativa estricta he visto que la estructura de clases deja mucho que desear por no decir que no tienen estructura de clases, y cada módulo suele estár lleno de código inconexo y repetido que nada tiene que ver con la clase en la que se aloja.
¿Y a que puede ser debido esto?  pues yo veo dos causas principales:  En primer lugar la mayoría de los programadores de .net tuvieron sus orígenes en Visual Basic, y cuando llegó el paradigma de la Programación Orientada a Objetos (OOP) al Visual Basic.Net la mayoría han seguido programando como lo hacían antes. Creando clases pero sin saber utilizarlas. Por otra parte he visto que la dirección de los proyectos siempre ha estado orientada a la producción y a los plazos más que a la calidad. Esto hace que cuando se comienza un proyecto, a los programadores se les ponga a tirar líneas de código casi al día siguiente de comenzar, con tal de tener algo para enseñar y cumplir plazos.
Al final lo que sucede es que el proyecto a medida que crece se hace tan complejo que se hace inmanejable y los desarrollos se alargan. Cuando un programador toca un módulo suele romper con facilidad otra funcionalidad anterior, y esto hace los proyectos muy difíciles de mantener y muy inestables. Además las pruebas se hacen cada vez más lentas y complejas.
Nada de esto sucedería si se proyectase adecuadamente siguiendo el paradigma de la OOP,  pues al estar todo encapsulado, las modificaciones son muy localizadas y se sabe perfectamente lo que hacen.  un proyecto así lleva algo más de tiempo de diseño, y se alarga el tiempo sin tirar ninguna línea de código, lo que puede impacientar a algún gestor, pero luego su implementación es rapidísima y con programadores junior, pues basta con darles todo bien especificado. En lugar de decir: -Tienes que hacer un módulo que tramite facturas. Y el programandor, que sabe poco o nada de  facturas, se pasa meses dando vueltas y tirando código para entregar un módulo lento y pesado que funciona con pinzas. Utilizando el paradigma de la OOP, basta con decir: -Tienes que crear una clase que se llame facturas y tenga estas propiedades y estos métodos que hagan exactamente esto.
Para ello se requiere una mano de obra menos cualificada y menos programadores,  pues se les da todo bien delimitado, lo que permite programar mucho más deprisa, los módulos son más pequeños, más rápidos y se integran perfectamente en el conjunto. Si alguna vez hay que hacer modificaciones se toca sólo ese módulo, sin miedo de que vaya a dejar de funcionar otra cosa, las pruebas son más rápidas.
Todo son ventajas, pero parece que en España no acaba de imponerse un modelo serio de Programación Orientada a Objetos, repercutiendo esto negativamente en la productividad del empleado, en la calidad del producto y en la competitividad de la empresa.

2 comentarios:

  1. Interesante, a veces casi siempre nos dejamos de llevar por las costumbres, debemos de dejar a un lado las paradigmas y ajustarnos al cambio.

    ResponderEliminar
  2. son muy acertados sus comentarios, esto es en realidad lo que sucedce con los programadores ques e han quedada con visual por eventos

    saludes

    ResponderEliminar