Ya que con la generación automática de código fuente obtenemos los mismos resultados, pero a un coste bajísimo, podríamos pensar que son la solución al problema que hemos planteado al inicio del artículo (la construcción de ‘AnotherAmazon.com’). Sin embargo la generación de código tiene numerosas pegas (no digamos ya la técnica de copiar-pegar-modificar) y por lo tanto no es la técnica apropiada para todos los proyectos.
Centrémonos por tanto en la generación de código fuente.
La generación de código tiene un escenario típico que es el de las interfaces entre diferentes capas, componentes, etc, lugares en los que una pequeña cantidad de información puede ser usada para generar todo el código repetitivo que se requiere (ej: Wsdl à Soap, mapeo OO à RDBMS, tablas à formularios) (en nuestro caso de tablas a listados Html y visualización Html de sus registros).
Existen básicamente 3 tipos de generación de código [ACG]:
* Templating. Se genera un armazón (o esbozo) de código fuente no funcional para ser editado, con el que se evita tener que escribir la parte más repetitiva del código (generalmente poco compleja). Suele ser una opción recomendable. Ejemplo: Si usamos Oracle JDeveloper para construir un nuevo Servlet, éste nos genera automática una clase ‘Servlet’ con los imports básicos y los métodos que tiene esta clase.
* Parcial. Se genera código fuente que implementa parcialmente la funcionalidad requerida, pero que el programador usará como base para modificar, integrar y/o adaptar a sus necesidades. No suele ser recomendable. Por ejemplo: generamos una aplicación para el mantenimiento de tablas de bbdd (como aplicaciones web realizadas con CodeCharge, o componentes BC4J del JDeveloper), en el momento en que queramos modificarla, integrarla con otros desarrollos o adaptarla a necesidades ligeramente diferentes, tenemos que bucear en enormes cantidades de código que no entendemos y que debemos modificar extensivamente.
* Total. Se genera código fuente funcionalmente completo pero que no va a ser modificado por el programador, sino que si es necesario se vuelve a regenerar. Por lo general tampoco suele ser un código excesivamente complejo. Recomendable. Ejemplo: generación de un Stub para un WebService en JDeveloper.
Centrémonos en la generación parcial (es decir generación automática + modificaciones y desarrollos en el mismo). Suele ser problemática, ya que:
* El código generado es lo suficientemente complicado como para ser difícil de modificar con respecto a la funcionalidad implementada.
* Su regeneración suele ser costosa ya que hay si regeneramos el código hay que volver a modificarlo para volver a adaptarla al problema.
* Todo este código acaba siendo código a mantener, y no podemos olvidar que el mantenimiento es el mayor coste de cualquier proyecto.
* Hace que el código sea dependiente de una herramienta adicional de desarrollo. Esto es muy restrictivo, ya que complica el mantenimiento (en muchísimas ocasiones no lo hace la misma empresa que lo desarrolló, o surgen nuevos entornos que hacen inviable el uso de esas herramientas de generación (por ejemplo CodeCharge al principio generaba JSPs, ahora Servlets!!)), es una dependencia más y además fuerte.
* La generación de código funcional (parcial o semitotal) suele darte casi la funcionalidad que necesitas, pero no exactamente la necesitada. Modificarla es difícil.
Una de las grandes metas de la ingeniería del software es crear software reutilizable, lo cual suele traducirse en código robusto, poco propenso a errores.
Entonces, ¿por qué no parametrizar todo ese código repetitivo pero diferente unificándolo en uno solo (es decir refactorizarlo)? Todo depende de las dimensiones de la aplicación, ya que esa refactorización se consigue generalmente mediante arquitecturas reflexivas. No olvidemos que desarrollar una arquitectura tiene su coste.
Sólo hay dos aspectos positivos de la generación parcial de código:
* Por lo general tiene un mejor rendimiento respecto a las a.r.
* Es más rápido de desarrollar que construir una a.r. (a no ser que ya la tengas implementada).
La generación de componentes webs (JSPs, ASPs, etc) asociados a tipos de objetos entraría en la categoría de generación parcial de código. Es evidente que podemos generar código que liste y visualize registros de tablas, pero este código generalmente forma parte de una aplicación que debe de integrarse con desarrollos específicos como código de seguridad, uso de tecnologías específicas de acceso a base de datos (por ejemplo un pool de conexiones), elementos de navegación, normas de estilo y visualización, uso de logs, mecanismos de personalización, servicios de impresión, etc, etc. Cuando nos enfrentamos a la construcción de aplicaciones medianas/grandes la generación de código suele ser muy problemática.
Qué es una arquitectura reflexiva
Tal y como aparece en [POSA] las arquitecturas reflexivas se han usado en multitud de sistemas y son especialmente apropiadas cuando necesitamos aplicaciones muy flexibles y adaptativas.
Usuarios que han visto este tema también han visto...
- Mantener Visitas
- Menús de navegación inútiles
- Estándares Web
- La navegabilidad
- Marketing en buscadores: ¿Todavía en su infancia?
- Versión imprimible de este documento
- Enviar por e-mail este documento
