Este pasado jueves di una breve charla durante la Barcelona Developers Conference sobre Programación Orientada a Aspectos. Fue una charla introductoria de cuarenta y cinco minutos en la que vimos los conceptos básicos de AOP, los problemas de implementación que nos encontramos al tratar los temas transversales de aplicación (cross-cutting concerns), las soluciones parciales que utilizamos actualmente y los beneficios que nos aporta la programación orientada a aspectos. Las demos con código estuvieron centradas en presentar varios conceptos de PostSharp y DynamicProxy, dos librerías que podemos utilizar para implementar aspectos en nuestras aplicaciones. En esta entrada voy a intentar resumir lo que ya fue una charla muy resumida de lo que es AOP.
¿Qué es AOP?
La programación orientada a aspectos es un paradigma de programación cuya principal intención es que escribamos buen código, código más limpio. Como comenté durante la charla este es un tema bastante curioso, porque el concepto de AOP es bastante antiguo (se desarrolló hace 15 años), mucha gente lo conoce, existen librerías desde hace también bastante tiempo, pero lo curioso es que en muy pocos proyectos he visto una implementación de aspectos.
De hecho, me ha sucedido varias veces, que lo primero que pregunta mucha gente cuando oye este término (sobre todo programadores de .NET) es: ¿Ya no programamos con orientación a objetos? Y la respuesta siempre es: No, AOP no sustituye la orientación a objetos. Pero lo que sucede es que la OOP es un modelo que se queda corto cuando tenemos que implementar temas transversales, cuando tenemos que implementar comportamientos que se utilizan en gran parte de las funcionalidades de negocio y además estos comportamientos no se pueden aislar fácilmente.
Cross-cutting concerns
Los temas transversales más comunes son el registro (logging), seguridad, transacciones, multithreading, interfaz de usuario, caché, validaciones, etc. Al final cuando tenemos toda esta funcionalidad implementada en nuestra aplicación, nos damos cuenta que tenemos el código esparcido por toda la aplicación, haciendo de ese código algo difícil de mantener y de depurar.
Los problemas que provoca tener que implementar toda esta funcionalidad transversal se pueden resumir en estos: más número de líneas, más código duplicado y código de negocio mezclado y acoplado con el código transversal.
Para minimizar el impacto de la implementación de esta transversalidad normalmente se utilizan distintas técnicas como puede ser la generación de código, programación funcional o proxies dinámicos, pero al no estar diseñados para implementar AOP no es la solución ideal para todos los casos.
Beneficios de la Programación Orientada a Aspectos
Al finalizar la charla comenté varios de los beneficios que obtenemos al aplicar AOP en nuestras aplicaciones. Estos beneficios quedan resumidos en la siguiente lista:
Menos costes – El coste de la creación de software es casi directamente proporcional al número de líneas de código que se hemos generado, y que luego tenemos que mantener.
Menos fallos – Menos código es sinónimo de menos fallos. Aunque los aspectos también pueden tener fallos, es más fácil solucionar un error en la clase de los aspectos que en cada uno de los métodos donde se aplica.
Aseguramiento de la Calidad – La programación orientada a aspectos, permite la activación de las funcionalidades transversales sin afectar la calidad de la aplicación.
Mejora el mantenimiento – Al reducir la dispersión del código transversal los desarrolladores pueden encontrar el código afectado por un cambio más fácilmente.
Mejora el trabajo en equipo – Los equipos de desarrollo no tienen que lidiar con la forma en que se debe implementar la funcionalidad transversal, permitiendo así que solo tengan que trabajar con el código de negocio. Además, los nuevos miembros tendrán una curva de aprendizaje menos prolongada para comenzar a ser productivos.
Hasta aquí este pequeño resumen, dejo también varios enlaces de referencia que mostré al final de la presentación así como el código que utilicé durante las demos.
Enlaces relacionados:
Aspect-Oriented Software Development
PostSharp
DynamicProxy
Descarga código fuente: BcnDevCon_AOP.zip (40.02 kB) - 231 descargas
Me surge una pregunta:
¿Qué relación le ves a esto con BDD? ¿Son complementarios, contrarios, lo mismo o simplemente dos visiones cosas que no tienen nada que ver?
Y ojo que esto puede ser la apertura de un muy buen debate
Hola Fernando, pues hasta donde yo sé BDD y AOP son dos metodologías de desarrollo, pero aparte de esto no les encuentro una relación directa. BDD está orientado a implementar una aplicación partiendo de su comportamiento y AOP a la forma de implementar las funcionalidades transversales. A partir de aquí, podríamos decir que son complementarias si utilizasemos aspectos para implementar las pruebas, pero esto no lo he visto, algo normal porque tampoco he visto ningún proyecto en el que se utilizase BDD
¿A ti qué te parece?
A mi me da mucho que pensar…
Le he estado dando muchas vueltas y creo que BDD no es del todo compatible con AOP. Es decir creo que fijándonos en el comportamiento de la aplicación y utilizando como punto de partida pruebas de MSpec (por decir algo), el proceso no nos va a llevar al uso de los aspectos.
Ahora bien, haciendo estas reflexiones me surgen algunas dudas: ¿Es testeable el código escrito con, por ejemplo, PostSharp? Porque con esto podríamos decir que si que es compatible con TDD. Aunque de cualquier forma el de DynamicProxy si que lo es, ¿no es así?
De cualquier forma, volviendo al tema, creo que metodologías como BDD nos llevarían a la creación de nuevos y diferentes artefactos, no al uso de AOP (que en realidad complementa esos artefactos). Pero claro, toda esta “discusión” se acaba si la respuesta es que AOP está pensado para usar en el proceso de refactorización de una aplicación. Una vez se ha escrito y se le quiere dar una forma limpia.
Y todo esto no quiere decir que reniegue de AOP. Lo veo muy útil y por ejemplo en un contexto de test unitarios me parece perfectamente complementario con cualquier metodología y librería que conozco…
¿Qué opinas/is?
Hola Alex, Fernando me ha “arrastrado” a este debate y me surge una duda: dices que tango BDD como AOP son metodologías de desarrollo, pero yo creo que AOP es más un paradigma que (como tú mismo dices en el título de la charla) hace tu código más robusto, pero no es una metodología.
Tal vez cuando la conoces y la usas frecuentemente se queda en tu método de programar, lo que algunos autores llaman el “cinturón de herramientas de un programador”. ¿Tú la ves como algo más que un paradigma?
Buenas Pablo, en el momento de escribir la respuesta a Fernando ya tenía ciertas dudas al decir que las dos eran metodologías de desarrollo, pero conforme ha pasado el día y he ido pensando en ello, cada vez estoy más convencido. De todas formas, creo que habría que diferenciar la AOP como paradigma y como metodología. De forma similar lo hacemos con la orientación a objetos, no podemos pensar en orientación a objetos sin pensar en un diseño orientado a objetos.
Si quieres hacer uso de aspectos en tu aplicación tienes que realizar un diseño orientado a aspectos y tener una arquitectura orientada a aspectos que te permita identificar claramente los aspectos transversales en la aplicación.
Veo que este debate dará juego…
Personalmente considero AOP como un paradigma que complementa la OOP. Igual que podría ser la Reactive Programming…
Creo que corremos peligro de confundir términos ingleses como “drive” y “oriented”. Es decir, puedo orientar mi arquitectura a servicios (SOA) usando como metodología el desarrollo guiado por los test (TDD).
La pregunta que habría que hacerse es ¿puedo orientar mi arquitectura a los aspectos y practicar BDD? ¿y TDD o DDD?
Y tengo más preguntas sin respuesta, pero vamos por partes
Pero claro, primero hay que responder las pregunta de si las librerías de apoyo para AOP son testeables…
Por partes,
Primero. Totalmente de acuerdo que AOP es un paradigma que complementa la OOP. La AOP como paradigma nos dice que la funcionalidad transversal se implementa con aspectos. Pero al igual que con el paradigma OO tenemos una metodologia de OOD, con los aspectos sucede lo mismo. Creo que tenemos que profundizar en esto, ver que es exactamente Diseño orientado a aspectos y arquitectura orientada a aspectos.
Segundo. Puedes practicar cualquiera de las tres metodologías (TDD, BDD y DDD) junto con AOP, como tu dices al ser una extensión de OO no tiene porque estar reñidas con los aspectos, ¿no?
Tercero. Tanto los aspectos como los métodos donde aplicas aspectos son testeables utilices Postsharp o DynamicProxy (hay que tener en cuenta que los proxies dinámicos no dan toda la capacidad de AOP como te la da Postsharp). De hecho utilizar aspectos hace que tu codigo sea más testeable. Tengo un post en borrador sobre esto que algún dia terminaré
Ahora empezamos a poner el tema interesante
Primero: Hay algo en lo que nos hemos puesto de acuerdo. Sobre la metodología no acabo de ver tu punto de vista ¿puedes explicármelo?
Segundo: Creo que también estás en lo cierto. Se puede utilizar cualquier metodología con AOP. Por ejemplo, si decido hacer SOA mis tests irán dirijidos a Servicios y no a otra cosa. Pero claro, no es tan simple o quizá no veo correctamente el paradigma. ¿Pruebo los aspectos? ¿O a caso solo puedo aplicarlo antes de hacer el test y en la refactorización de código?
Tercero: eso me parece genial ¿cómo podríamos testear aspectos? ¿o no sería necesario y valdría con testear el código?
Gracias tío!
Alex, creo que te entiendo pero te voy a hacer una pregunta que aclarará bastante si AOP es una metodología o un paradigma:
¿La primera vez que usaste aspectos en un proyecto lo decidiste a priori o viste que era bueno y los añadiste a posteriori?
Esto tiene relación con lo que decía del “cinturón de herramientas”, si en un proyecto uso aspectos y veo que es bueno, en el siguiente proyecto que haga ya lo usaré desde el inicio, independientemente de si hago TDD, BDD o lo que sea.
Hola Pablo, también entiendo tu postura, pero lo que yo digo es que AOP no sólo es un paradigma, para aplicar aspectos tienes que seguir una metodología algo diferente que con OO.
Imagina que estas programando tu bonita aplicación con programación estructurada y un día descubres que hay algo que se llama objeto y decides utilizar objetos. Con solo aplicar el paradigma de OO no te vale, tienes que cambiar la forma de pensar en procedimientos y subrutinas y demás y utilizar esos objetos. Tienes que cambiar tu metodología, tienes que utilizar un diseño orientado a objetos.
Ese es mi planteamiento con los aspectos, cuando decides utilizar aspectos no te es suficiente con implementar aspectos, tienes que cambiar la forma de programar, tienes que seguir una metodología orientada a aspectos (que no dirigido). Lo que queda por ver es cómo cambiamos nuestra metodología, que hacemos diferente.
Continuará…
A la hora de testear hay gente partidaria de probar todo los métodos con los aspectos incluidos y otros que dicen que solo hay que probar el método desactivando el aspecto. Yo no lo tengo muy claro, pero creo que hay que probar el método donde se aplica y el aspecto por separado, en caso contrario ya no estaríamos hablando de tests unitarios.