finis coronat opus

Hace unos dias Merrick Schincariol publico un post para intentar aclarar lo que realmente se encuentra tras las siglas de AOP. Quizás no sea el articulo más completo sobre AOP pero si el más *claro* que he leido al respecto. Hace hincapie en algo que normalmente suele quedar enterrado bajo el mejunge de conceptos técnologicos existentes alrededor de AOP y con lo que estoy completamente de acuerdo:

"If you remember nothing else about AOP, remember that it is fundamentally about separation of concern. Filtering, interceptors and other implementation techniques that seem to dominate the AOP discussion are simply recipes for applying the AOP methodology. They are not AOP in and of themselves".

A pesar de ello hubo algo que no me acabo de convencer : la implementación del ejemplo en AspectJ. Sí , si ya se que solo es un ejemplo y que la implementación no es lo fundamental pero me gustaria ofrecer la contrapartida a ese ejemplo en otro de los frameworks existentes para AOP: Aspectwerkz. Dejo para otro post la explicación del porque de mi inclinación por AspectWerkz y no por AspectJ. Partimos de la misma clase desligada de todo aspecto no relacionado directamente con su finalidad ultima: imprimir.

public class PrintServer {
    // private variables
    // ...
    
    // constructor
    PrintServer() {
      // ...
    }
    
    public void printDocument(Document doc) {
        // ...
    }
    
    public PrinterInfo getPrinterInfo() {
        return retrievePrinterInfo();
    }
    
    // other printing methods 
    // ...
}

Y construimos el resto de requerimientos en base a aspectos de esa clase:

// Para sincronizar el acceso
import EDU.oswego.cs.dl.util.concurrent.Mutex;

import org.codehaus.aspectwerkz.advice.AroundAdvice;
import org.codehaus.aspectwerkz.joinpoint.JoinPoint;

public class SynchronizationAdvice extends AroundAdvice {

    private Mutex m_mutex = new Mutex();

    public SynchronizationAdvice() {
        super();
    }

    public Object execute(final JoinPoint joinPoint) throws Throwable {
        System.out.println("Acquiring mutex\t" + Thread.currentThread());
        m_mutex.acquire();
        System.out.println("Has mutex\t\t" + Thread.currentThread());
        Object result = joinPoint.proceed();
        m_mutex.release();
        System.out.println("Releasing mutex\t" + Thread.currentThread());
        return result;
    }
}

// para tracear las entradas y salidas...
import org.codehaus.aspectwerkz.advice.AroundAdvice;
import org.codehaus.aspectwerkz.joinpoint.JoinPoint;

public class LoggingAdvice extends AroundAdvice {

    public LoggingAdvice() {
        super();
    }

    public Object execute(final JoinPoint joinPoint) throws Throwable {
        MethodJoinPoint jp = (MethodJoinPoint)joinPoint;
        System.out.println(" entering " + jp.getTargetClass().getName() + 
                           "::" + jp.getMethodName());
        final Object result = joinPoint.proceed();
        System.out.println(" exiting " + jp.getTargetClass().getName() + 
                           "::" + jp.getMethodName());
        return result;
    }
}

// Y finalmente para cachear...
import org.codehaus.aspectwerkz.advice.AroundAdvice;
import org.codehaus.aspectwerkz.joinpoint.JoinPoint;

public class CachingAdvice extends AroundAdvice {

    protected static Object cachedResult =null;

    public CachingAdvice() {
        super();
    }

    public Object execute(final JoinPoint joinPoint) throws Throwable {

        if (cachedResult != null) {
            return cachedResult;
        }
        final Object result = joinPoint.proceed();

        cachedResult = result;
        return result;
    }
}

Como se puede observar todas los aspectos se implementan como clases Java corrientes y molientes (gran, EMHO, diferencia con respecto a AspectJ) heredando de AroundAdvice, una clase proporcionada por AspectWerkz que permite controlar el antes y el despues de la ejecucion de ciertos metodos. ¿Qué metodos?. Uuups. Se me olvidaba. Para determinar la asociación de un aspecto a un determinado punto de nuestro codigo poseemos varios metodos: uno, el que detallo a continuación por simplicidad, que permite definir en un XML estas relaciones, y dos, la utlización de los llamados atributos en tiempo de ejecución que no son sino cabeceras estilo Javadoc delante de ciertos metodos que permiten determinar, por ejemplo, que aspectos estan relacionados con el metodo en curso (de una manera muy similar a como se especifica en XDoclet). ¿Diferencias?. El segundo de los metodos implica una precompilación del codigo para generar lo que se denomina "weave model", que recopila la información de estos atributos.

Utilizando el primero de los metodos, tendriamos un XML como el siguiente:

<?xml version="1.0"?>
<aspectwerkz>

    <advice name="logging"
            class="LoggingAdvice"
            deployment-model="perJVM"
            attribute="log"/>

    <advice name="caching"
        class="CachingAdvice"
        deployment-model="perInstance">
    </advice>

    <advice name="synchronization"
        class="SynchronizationAdvice"
        deployment-model="perJVM"/>


    <aspect class="PrintServer">
        <pointcut type="method" pattern="*getPrinterInfo()">
            <advices-ref name="caching"/>
        </pointcut>
    </aspect>

    <aspect class="PrintServer">
        <pointcut type="method" pattern="*  printDocument(..)">
            <advice-ref name="synchronization"/>
        </pointcut>
    </aspect>

        <aspect class="PrintServer">
            <pointcut type="method">
                <pattern>* p*(..)</pattern>
                <advice-ref name="logging"/>
            </pointcut>
        </aspect>

</aspectwerkz>


Por ultimo resaltar la posibilidad de la utilización de *expresiones regulares* para determinar los metodos (pattern) a los que queremos aplicar el aspecto.
En fin, sigamos la implementación que sigamos, a nadie se le escapa, que aunque incipiente, AOP abre interesantes caminos en el campo del desarrollo software. Por ahora no existe una base amplia de IDEs que faciliten el desarrollo, exceptuando el proporcionado por AspectJ (aunque la gente de Eclipse ya esta trabajando en un plug-in), pero bueno todo llegará... P.D.: No , martin no se me ha olvidado lo de la conversión de patrones ;-), estoy en ello.