Programación Orientada a Aspectos.
La Programación Orientada a Aspectos (POA) es un paradigma de programación relativamente reciente cuya intención es permitir una adecuada modularización de las aplicaciones y posibilitar una mejor separación de incumbencias. Gracias a la POA se pueden encapsular los diferentes conceptos que componen una aplicación en entidades bien definidas, eliminando las dependencias entre cada uno de los módulos. De esta forma se consigue razonar mejor sobre los conceptos, se elimina la dispersión del código y las implementaciones resultan más comprensibles, adaptables y reusables.
Objetivo
El principal objetivo de la POA es la separación de las funcionalidades dentro del sistema:
• Por un lado funcionalidades comunes utilizadas a lo largo de la aplicación.
• Por otro lado, las funcionalidades propias de cada módulo.
Conceptos
• Aspect (Aspecto) es una funcionalidad transversal (cross-cutting) que se va a implementar de forma modular y separada del resto del sistema. El ejemplo más común y simple de un aspecto es el logging (registro de sucesos) dentro del sistema, ya que necesariamente afecta a todas las partes del sistema que generan un suceso.
• Join point (Punto de Cruce o de Unión) es un punto de ejecución dentro del sistema donde un aspecto puede ser conectado, como una llamada a un método, el lanzamiento de una excepción o la modificación de un campo. El código del aspecto será insertado en el flujo de ejecución de la aplicación para añadir su funcionalidad.
• Advice (Consejo) es la implementación del aspecto, es decir, contiene el código que implementa la nueva funcionalidad. Se insertan en la aplicación en los Puntos de Cruce.
• Pointcut (Puntos de Corte) define los Consejos que se aplicarán a cada Punto de Cruce. Se especifica mediante Expresiones Regulares o mediante patrones de nombres (de clases, métodos o campos), e incluso dinámicamente en tiempo de ejecución según el valor de ciertos parámetros.
• Introduction (Introducción) permite añadir métodos o atributos a clases ya existentes. Un ejemplo en el que resultaría útil es la creación de un Consejo de Auditoría que mantenga la fecha de la última modificación de un objeto, mediante una variable y un método setUltimaModificacion(fecha), que podrían ser introducidos en todas las clases (o sólo en algunas) para proporcionarles esta nueva funcionalidad.
• Target (Destinatario) es la clase aconsejada, la clase que es objeto de un consejo. Sin AOP, esta clase debería contener su lógica, además de la lógica del aspecto.
• Proxy (Resultante) es el objeto creado después de aplicar el Consejo al Objeto Destinatario. El resto de la aplicación únicamente tendrá que soportar al Objeto Destinatario (pre-AOP) y no al Objeto Resultante (post-AOP).
• Weaving (Tejido) es el proceso de aplicar Aspectos a los Objetos Destinatarios para crear los nuevos Objetos Resultantes en los especificados Puntos de Cruce. Este proceso puede ocurrir a lo largo del ciclo de vida del Objeto Destinatario:
o Aspectos en Tiempo de Compilación, que necesita un compilador especial.
o Aspectos en Tiempo de Carga, los Aspectos se implementan cuando el Objeto Destinatario es cargado. Requiere un ClassLoader especial.
o Aspectos en Tiempo de Ejecución.
Spring AOP
AOP es útil para realizar tareas puntuales que no encajan de forma natural en nuestras entidades ni en nuestra lógica de negocio; estas tareas podríamos implementarlas en la lógica de negocio por ejemplo, pero estaríamos ensuciando nuestras clases con código que no les corresponde controlar. Imagínemos por ejemplo el envío de un mail al administrador cuando un usuario nuevo ha sido dado de alta. La función de enviar un mail no está relacionada en lo absoluto con las funciones que debería de hacer una clase encargada de administrar usuarios. Para no mezclar estas funciones podríamos utilizar perfectamente AOP y definir fuera de nuestro código que cuando se dé de alta un usuario nuevo se envíe un mail a una dirección determinada. Hay varios campos para los que AOP se puede emplear de forma satisfactoria, como puede ser para realizar Transacciones, para Depurar un programa registrando lo que está sucediendo en los métodos, o para implementar unas políticas de seguridad. Spring tiene implementadas clases para controlar el tema de las Transacciones y el de registro de acciones. También existe un framework de seguridad ( Acegi ) que va a formar parte de Spring. Pero si queremos implementar otro tipo de aspectos personalizados debemos definirlos nosotros mismos implementando unas interfaces creadas para tal efecto, y precisamente éste va a ser el objetivo de este artículo, la definición de aspectos personalizados en Spring.
