|
Meto mi cuchara (o cucharón...jejeje) No olvidemos que ni OOP ni programación estructurada y hasta UML no son la panacea. Es cierto que cada uno tiene sus pros y contras, pero al final no dejan de ser meros paradigmas. Muchas veces tenemos algo funcional y muy optimizado y al querer migrarlo hacia otro paradigma terminamos con algo que ni es funcional y mucho menos optimizados.
Antes de hacer alguna migración de este tipo conviene hacerse algunas preguntas:
¿El código que tengo ya no me proporciona las herramientas que necesito para mejorar mi programa?
¿El nuevo paradigma lo entiendo mejor que el anterior?
¿El resultado final (lo que hace el programa) será mejor tan solo por cambiar de paradigma?
Por decil algunos....Aclaro que me refiero a desarrollos profesionales (de los que se cobran) ya que si es algo didáctico entonces si no hay impedimento para aventarse e ir conociendo un uevo paradigma desde uno que ya conocido.
El caso de los forms que contienen lógica de negocios resulta interesante porque en ocasiones son una solución muy sencilla y rápida para tener nuestro código modularizado, digamos que tenemos un formulario TFactura que contiene un método Muestra que acepta como parámetro un número de factura. El formulario, o màs bien la clase, se encarga de todo lo necesario: ir por el registro al datamodule, cargarlo y mostrarlo. De manera que en cualquier parte de nuestra aplicación que necesitemos mostrar una factura, simplemente usamos ese formulario sin mucha complicación. Aunque esto violaría muchos principios en otros paradigmas, es sin embargo, un paradigma válido ya que se cumple la función. Es perfectamente mantenible porque cambiado el formulario cambiamos todo el comportamiento en cualquier parte de la aplicación y además es transportable a otras aplicaciones similares.
Otro punto a considerar es que el IDE de Delphi no está precisamente orientado a hacer uso extensivo de OOP (aunque trae muchisimas ayudas para ello en sus últimas versiones). El IDE desde su nacimiento se enfocó a desarrollar aplicaciónes rápidamente (RAD) por lo que muchas cosas se pasan por alto, por ejemplo el Binding y los controles de acceso a datos, con ellos se hacen formularios de captura rápidamente pero se "violan" otros paradigmas.
En fin, que considero que en el desarrollo de aplicaciones a nivel profesional es mejor tomar un poco de cada paradigma y utilizarlo correctamente para que nuestro código sea mantenible y sencillo para nuestros propósitos.
|