Join Point

Nuevo artículo en AOP@Work: Rompiendo mitos

  El 14 de febrero los "enamorados" de la Programación Orientada a Aspectos recibimos otro regalo de manos de Ramnivas Laddad. Laddad es un nombre bien conocido en los círculos de la AOP, autor de AspectJ in Action, un gran libro, y ponente en la mayoría de los "saraos" relacionados con Java, como muestra, su magnifica conferencia Practical AOP en JavaPolis 2005

  Y es que parece que 2006, y esta vez sí, va a ser el año de la AOP. Desgraciadamente, se lleva mucho tiempo hablando de ella y se ha convertido en tema "hype". Realidades como las de Spring, JBoss, y artículos como AOP myths and realities - Beyond hype and misunderstandings pueden ayudar a ver la AOP como una solución factible y no como un tema más de los debates sin sentido tan habituales en el mundo informático y la presa del corazón.

  El artículo, que ocupa impreso unas 15 páginas A4, trata de desmontar 15 mitos habituales de la AOP. A continuación comentaré muy brevemente mi primera impresión sobre ellos.

Mito 1: AOP es buena solamente para trazas y logs

Realidad: AOP es idónea para muchas otras preocupaciones transversales (crosscutting concers)

Como dice el artículo, son los ejemplos clásicos que aparecen siempre, son el "hola mundo" de la AOP. Ambos problemas son padecidos por cualquier programador y sirven de forma estupenda para mostrar el potencial y la problemática que intenta solucionar la AOP.

Mito 2: AOP no resuelve ningún problema nuevo

Realidad: Es cierto, no lo hace

¿Que problemas resuelve la OOP frente a la programación estructurada?. El objetivo de la AOP es mejorar la modularidad del software, y por tanto, mejorar la reutilización, la evolución y dinamicidad de los sistemas software, y un largo etcétera.

Resumiendo, se puede decir que la "revolución" que plantea la Programación Orientada a Aspectos, es en el cómo solucionar los problemas. Además, considero que con este paradigma por fin se puede tratar los requisitos no funcionales a la altura que merecen y que es necesaria para que nuestra Ingeniería de Software sea algo real.

Mito 3: Interfaces bien diseñadas no hacen necesaria la AOP

Realidad: Las buenas interfaces son estupendas, pero no reemplazan a los aspectos

Pues si, un buen diseño de las interfaces esta muy bien, pero no sustituye las ventajas/necesidad de usar aspectos.

Mito 4: Los patrones de diseño hacen innecesaria la AOP

Realidad: Los patrones de diseño pueden introducir complejidad no existente en AOP

Muchas veces he oído comentar que lo que hace la AOP podría solucionarse con un par de patrones (mediator, visitor, etc, etc). Primero, no estoy de acuerdo, y segundo, lo que sale es un churro tremendamente complejo. En el imperio de los POJO soluciones como AOP e IoC se imponen a complejos patrones que necesitan de infinitas clases auxiliares e interfaces.

El artículo hace una crítica muy bien fundamentada del abuso del patrón Chain of Responsability (CoR) para solucionar problemas propios de la AOP. Recomendable leer todo el punto de artículo con los ejemplos para comprender mejor el potencial de la AOP en los problemas cotidianos.

Mito 5: Los proxies dinámicos hacen innecesaria la AOP

Realidad: AOP proporciona una solución más simple que los proxies dinámicos

Cuando leí el título de este punto me sorprendió. Lo que Laddad trata de decir es que usar los proxies dinámicos directamente es una mala solución. Sin embargo, hay que recordar que los proxies dinámicos son utilizados por numerosos frameworks AOP y es que hasta donde yo sé es de las únicas formas de tener AOP verdaderamente en tiempo de ejecución. Si alguien conoce más alternativas me gustaría saberlas.

Mito 6: Los frameworks de aplicación (application frameworks) hacen innecesaria la AOP

Realidad: Los frameworks introducen limitaciones no existentes en AOP

Frameworks de aplicación, como EJB, tienen una curva de aprendizaje muy elevada, sin embargo, en AOP hay muy pocos conceptos y una vez que les dominas no tienes limitaciones de ningún tipo. Si bien es cierto, que los servicios los tienes que implementar tu

Mito 7: Las anotaciones hacen innecesaria la AOP

Realidad: Anotaciones y AOP son altamente complementarias

Realmente las anotaciones van a incrementar el uso de AOP. Uno de los problemas que había para la adopción de la AOP es que necesitábamos un nuevo lenguaje. Las anotaciones y la definición de aspectos mediante XML dará menos miedo a la hora de apostar por la AOP. Además los programadores, en un futuro no muy lejano, nos vamos a tener que acostumbrar a tener muchas arrobas en nuestro código.

Yo personalmente prefiero las definiciones en XML, aunque luego sea un infierno, pero es la mejor forma de sacar esas definiciones fuera del código.

Mito 8: Los aspectos oscurecen el flujo del programa

Realidad: AOP aumenta el nivel de abstracción

La verdad es que este mito tiene parte de verdad y es que a medida que vamos añadiendo abstracción y alteramos el flujo normal del sistema, perdemos un poco la trazabilidad de la ejecución. Lo mismo pasa cuando usamos IoC y otras muchas cosas pero también es cierto que ganamos modularidad y otras cosas. Al final compensa.

Mito 9: Depurar con aspectos es duro

Realidad: AOP simplifica la depuración de la funcionalidad transversal

Al hilo del mito anterior, es cierto que en algún momento pueda parecer más difícil ya que añadimos capas pero es que la propia depuración es una preocupación transversal que puede ser tratada por la AOP como la tarea de realizar logs.

La AOP es en si misma una herramienta para facilitar la depuración. Incluso es el pilar para los sistemas software capaces de "autocurarse".

Mito 10: Los aspectos pueden romperse si las clases evolucionan

Realidad: Aspectos escritos pobremente puede romperse si las clases evolucionan

Pues es evidente que si la definición de aspectos no es la más adecuada, cuando modifiquemos las clases se va a ver alterada. El artículo ofrece algunas pistas para minimizar ese riesgo. Lo mejor de todo: hacer PRUEBAS!.

Mito 11: Los aspectos no pueden ser unidades testeables

Realidad: Los aspectos pueden ser unidades testeables tan fácilmente como las clases

Nada más alejado de la realidad, AOP es un mecanismo potentísimo para hacer pruebas y no tiene grandes problemas para ser sometido a ellas.

Como comentaba en una entrada anterior, existen herramientas de pruebas, al estilo JUnit, específicas para AOP como aUnit, artículos como Unit test your aspects, ...
Para más información ver http://www.csc.ncsu.edu/faculty/xie/aoptv.html

Mito 12: Las implementaciones de AOP no requieren un nuevo lenguaje

Realidad: Todas las implementaciones de AOP usan un nuevo lenguaje

Como comentaba unas líneas más arriba yo creo que el uso de anotaciones se va a terminar imponiendo aunque personalmente soy bastante más partidario de las definiciones en XML. Pero bueno, ya se verá. Lo que es cierto es que esto no puede ser utilizado como excusa.

Mito 13: AOP es simplemente demasiado compleja

Realidad: Si, pero aún más simple que las alternativas

El título lo dice todo .

Mito 14: AOP promueve diseño descuidado

Realidad: Se necesita experiencia para usar cualquier tecnología óptimamente

Ciertamente se puede hacer un mal uso de la AOP. Todavía es necesario un mayor rodaje de la AOP y sobre todo de los profesionales que la utilizan. Lo mismo sucedió en su tiempo con el paradigma de la Programación Orientada a Objetos.

Mito 15: La adopción de AOP es todo o nada

Realidad: AOP puede ser adoptado incrementalmente

Es algo que vengo comentando desde siempre. Hay muchas formas de usar AOP, lo importante es ir incorporándolo poco a poco en nuestro software y cada vez de forma más explícita. Valga esta última frase como conclusión de esta entrada.

Posted at 05:52PM feb 18, 2006 by Ricardo Santamaría Bogónez in AOP  |  Comentarios[1]