Documente Academic
Documente Profesional
Documente Cultură
Para iniciarnos en el mundo de la POA, qué mejor que hacerlo con el clásico programa
“Hola Mundo”. Empecemos entonces. Los requerimientos para nuestro sistema son:
• Que muestre por pantalla la expresión “¡Hola Mundo!”
• Que antes del “¡Hola Mundo!”, se muestre un mensaje que diga que se está por ver
un mensaje y similarmente, luego del “¡Hola Mundo!” se muestre el siguiente el
siguiente mensaje “Un mensaje ha sido mostrado”.
“¡Hola Mundo!” representará la funcionalidad básica del sistema, mientras que los
mensajes antes y después constituirán el aspecto de logging.
public class HM {
private String mensaje;
public HM() {
this.mensaje = "¡Hola Mundo!";
}
public void setMensaje(String M){
this.mensaje = M;
}
public String getMensaje(){
return this.mensaje;
}
public void showMensaje(){
System.out.println(this.mensaje);
}
}
La clase HM tiene un campo privado mensaje, que es inicializado con ¡Hola Mundo! en
su constructor. Como el campo es privado, esta clase brinda dos métodos para manejar
el mensaje, setMensaje y getMensaje, para setear un nuevo mensaje y para accederlo,
reespectivamente. Por último, cuenta con el método showMensaje para mostrar el
mensaje por pantalla.
Nos queda solamente poner la clase principal, la cual usará la clase HM. La clase
principal se muestra en el siguiente cuadro.
before(): mensajesAImprimir(){
System.out.println("Ahora se mostrará un mensaje");
}
after(): mensajesAImprimir(){
System.out.println("Un mensaje ha sido mostrado");
}
before(): mensajesAImprimir(){
System.out.println("Ahora se mostrará un mensaje");
}
after(): mensajesAImprimir(){
System.out.println("Un mensaje ha sido mostrado");
}
De esta manera, tenemos una funcionalidad básica “limpia”, donde todo el código se
refiere a la implementación de la funcionalidad básica solamente. Por otro lado,
tenemos completamente encapsulado nuestro aspecto de logging. Cualquier
modificación sobre el logging será mucho más sencilla debido a que su código está
correctamente encapsulado.
Sin POA, nuestro sistema hubiera quedado así:
En la figura de arriba podemos ver los aspectos que interactúan con el método
showMensaje de la clase HM. Para el método, nos dice qué advices interactúan con él, y
cuándo. En este caso, los advices before y after del aspecto logging, y también el
nombre del pointcut involucrado (mensajesAImprimir).
El punto de vista del aspecto lo refleja la siguiente figura. En la misma vemos donde y
cómo se usa el poincut mensajesAImprimir. Nos dice que existe un advice que
aparecerá antes del showMensaje de la clase HM y otro después.
Esta es una manera muy clara, útil y natural de expresar el comportamiento de los
aspectos sobre el código base. Podemos ver estando en el código base donde se meterán
los aspectos, y del lado de los aspectos, podemos ver donde se aplicarán en el código
fuente.
Aquí les dejo links interesantes para seguir con AspectJ y Programación Orientada a
Aspectos.
Los metadatos son datos sobre datos. Muchos tenemos la intuición que un sistema es
más que la frágil sintaxis de sus instrucciones. La sintaxis como sabemos es muy
proclive a cambios, y esto ocasiona numerosos problemas. Una de la manera de hacer
más fuerte el contenido de nuestro sistema es agregándole semántica al código, de
manera de depender de algo más robusto que la sintaxis. De eso se trata los metadatos.
Ahora, debemos anotar las porciones de código relacionadas con los mensajes a
imprimir. En nuestro caso, la porción de código que queremos anotar es el método
showMensaje de la clase HM. La anotación se hace a través del carácter especial @ de
la siguiente manera:
public class HM {…
@mensajeAImprimir
public void showMensaje(){
System.out.println(this.mensaje);
}
}
Con esta anotación se establece que el método showMensaje forma parte del conjunto
de métodos que me interesa loguear. Este conjunto representa un nivel más de
abstracción, más sólido que la sintaxis del código. Por lo tanto, los aspectos basados en
este nivel superior, son más reusables y evolucionables. Es decir, yo puedo cambiar el
nombre del método, o sus parámetros, o cualquier otro detalle sintáctico, pero mientras
siga siendo parte de los métodos que quiero logear, la anotación mantendrá su
significado y el aspecto no se verá afectado por los cambios sintácticos. Claramente
constituye un avance importante.
Bien, sólo nos queda mostrar cómo es la especificación de los aspectos basados en
anotaciones.
Este pointcut captura todas las llamadas a métodos anotados con la anotación
mensajeAImprimir. El aspecto queda definido así:
before(): mensajesAImprimir(){
System.out.println("Ahora se mostrará un mensaje");
}
after(): mensajesAImprimir(){
System.out.println("Un mensaje ha sido mostrado");
}
Como establecimos anteriormente, este nuevo aspecto está basado sobre las
anotaciones, y es “resistente” a modificaciones sintácticas. Pero no todo lo que brilla es
oro. La contra que tienen las anotaciones es que se suele caer en la tentación de abusar
de ellas. Si esto ocurre, las anotaciones terminan ensuciando mucho nuestro código,
insertando cosas extras que luego no se entienden. Siempre teniendo en mente que las
anotaciones son un arma extra que tiene el programador para hacer más robusto y
confiable su código, los riesgos de que surjan los efectos negativos de las anotaciones
son casi nulos. Las anotaciones deben tener sentido, para así formar una visión más
abstracta del código, con más significado que la sintaxis del código.