Sobre la encuesta del mes: AOP

La encuesta de este mes va sobre AOP. Parece ser que todos nos estamos planteando evaluarla, pero ninguno se quiere meter con ella. Personalmente creo que la AOP está un poco verde para emplear en proyectos en produccrión; por un lado los desarrolladores arán no están muy formados en ella e incluirla puede suponerles una carga mas que una ayuda. Por otro empelarla supone verse ligado a una serie de herramientas y librerýas de terceros, que a dýa de hoy no permiten cambiar de una a otra con facilidad, y que no siempre ofrecen suficientes garantýas de continuidad en el futuro.



En una ocasrión se le preguntý a Gosling porquý nos e habýa incluido soporte para AOP en el JDK 5.0. Eso sin duda hubiese resuelto buena parte de las reticencias para usar AOP. Su respuesta fue tajante: AOP aún está muy verde, necesita más tiempo. Yo coincido con ýl. Creo que es el momento de experimentar y aprender, pero aún no de emplear de modo rutinaria. Claro que esto es sýlo mi opinrión. ¿Cuál es la tuya?.



Si no sabes de que va la AOP te recomiendo que leas el tutorial de jH de AOP , y si eres un poco vago o no tienes tiempo puedes leer lo que yo he escrito debajo de esta líneas, pero vaya por delante que estoy muy lejos de ser un experto en AOP, y espero que me disculpýis (y que me corrijýis) aquellos que estáis más puestos en el tema que yo si he escrito alguna incoherencia.









La Programacrión Orientada a Aspectos (AOP) pretende permitir una adecuada modularizacrión de las aplicaciones y posibilitar una mejor separacrión de los distintos "aspectos" que hay en ella. La AOP pretende capturar los diferentes aspectos que componen una aplicacrión en entidades bien definidas, y eliminado las dependencias entre cada uno de los módulos. De esta forma se consigue razonar mejor sobre los aspectos, se elimina la dispersrión del código y las implementaciones resultan más comprensibles, adaptables y reutilizables.



¿Y que son estos aspectos? Un aspecto pretende capturar un comportamiento parcial comýn a varis unidades de código. Por ejemplo imaginaos una clase que permite realizar operaciones sobre una base de datos. En funcrión de los roles de los usuarios y de si la operacrión es sýlo de consulta o modifica informacrión hay unos usuarios autorizados a realizarla y otros no. Por lo tanto antes de ejecutar el cuerpo de un método debemos chequear si este usuario tiene o no permiso para invocarlo. Ese código nada tiene que ver con la lýgica de negocio capturada por el método, y además tendrý que ser replicado en todos los métodos de la case. Por ello entorpece a comprensrión del código y fomenta el copypaste y baja la reutizabilidad del código.



Otra definicrión un poco más týcnica, de Gregor Kickzales es: ýUn aspecto es una unidad modular que se dispersa por la estructura de otras unidades funcionales. Los aspectos existen tanto en la etapa de diseño como en la de implementacrión. Un aspecto de diseño es una unidad modular del diseño que se entremezcla en la estructura de otras partes del diseño. Un aspecto de programa o de código es una unidad modular del programa que aparece en otras unidades modulares del programaý .



¿Cómo funciona la AOP en la práctica? AL AOP te permite programar los aspectos de un modo independiente (chequeos de seguridad en base a roles en nuestro ejemplo) y luego definir unos puntos de intercepcrión (el principio de los métodos que requieran el chequeo de seguridad), en los cuales se ýinsertarýý el código del aspecto, bien dinýmicamente en tiempo de ejecucrión, o bien tras una precompilacrión del código. Es de este modo como se logra tener unas unidades más independientes, reutilizables y fýciles de comprender.



¿Quieres empezar a jugar con esto? Pues el tutorial de jH de AOP incluye ejemplos, no se a que esperas XD.



Bueno, ahora os toca hablar a vosotros: ¿Qué opinýis de la AOP esa? ;)