AOP: por qué digo que el enfoque basado en Atributos no es serio

 Éste  no va a ser un artículo más de Programación Orientada a Aspectos (AOP, o Aspect-Oriented Programming) en plataforma .NET. No voy a hacer aquí una recapitulación de los problemas que han venido marcando el agotamiento de la Programación Orientada a Objetos (OOP, u Object-Oriented Programming) ni la necesidad de desenredar aspectos en el tangled code (código enredado) para poder enhebrarlos (aspect weaving) en ejecución. Mi intención, en realidad, es cuestionar el enfoque clásico que se ha venido dando para implementar AOP en .NET
 
Allá por Marzo de 2002, MSDN Magazine publicaba un artículo mostrando cómo AOP habilita mejor encapsulamiento de código y reuso. Como concepto, para alguien que no conoce AOP, no es malo del punto de vista de que plantea cuáles son los síntomas de agotamiento de OOP. Si revisamos otra cuestión como timing, es loable que .NET ya se estuviese ocupando de AOP siendo que por aquellos días era una plataforma recién lanzada (comparativamente, el medio on-line JavaWorld el mismo mes también se había ocupado de divulgar los beneficios de AOP)
 
En JavaWorld habían hecho girar las cuestiones técnicas en el framework creado por Gregor Kiczales allá por 1996: AspectJ. Es decir, se basaban en una extensión extraoficial de Java (que incluye compilador propio) como implementación políticamente correcta de un concepto que excedía a Java misma (enfocada en OOP, no en AOP)
 
En cambio, en el artículo de .NET, las cuestiones técnicas giraron en torno de conceptos propios de la plataforma que, admitamoslo, tampoco apunta a AOP sino nuevamente a OOP. Basicamente, la clase System.ContextBoundObject tiene la particularidad de ejecutarse en un contexto propio donde tiene habilitada la intercepción. El problema es que la forma de especificar puntos de unión (joinpoints) es a través de atributos (attributes), también llamados metadatos (metadata). Más específicamente el que se usa es System.ContextAttribute
 
Debo admitir que el desacoplamiento se logra: toda la lógica del aspecto (seguridad, transaccionalidad, trazabilidad, etc) va a parar a clases específicas, dejando de estar enredado en el código que también guarda una semántica concreta, del negocio o aplicación. La formalización del mecanismo en como esto se logra es muy compleja y cuestionable del punto de vista de la claridad del código y el acoplamiento a API’s específicas, pero eso es material para otra crítica. Ahora simplemente voy a limitarme a decir qué es lo que no me gusta: lo que no acepto de especificar puntos de unión mediante atributos
 
Concretamente, como yo lo veo, el código sigue quedando enredado. Si bien antes teníamos un enriedo mayor porque líneas de código del aspecto se entrelazaban con las de la lógica pura de aplicación, ahora aún nos queda el atributo, que decora al método de aplicación a interceptar, enredado al mismo. Dicho en otras palabras, cualquier modificación a los puntos de unión de un método nos va a obligar a recompilar el mismo aún cuando no haya sufrido cambios. Mal veo yo a eso
 
Un esquema más elegante nos debería permitir manejar reglas de enhebrado (weaving rules) en un lugar aparte (i.e.: archivo separado), de modo tal que aspecto y lógica de aplicación puedan efectivamente evolucionar por separado, así como también la colocación o quita de puntos de unión entre ambos
 
Así es como trabajan otros frameworks de AOP como Aspect#, RAIL o Spring.NET. Voy más allá: el enfoque basado en System.ContextBoundObject y System.ContextAttribute no es errado sino incompleto. Una solución a este dilema puede considerar, mediante un lenguaje específico de dominio (DSL o Domain Specific Language) definir una gramática para especificar reglas de enhebrado sobre clases tradicionales y que esto implique generación automática de clases basadas en ContextBoundObject y decoradas con ContextAttribute (para lograr el enhebrado). La complejidad del mecanismo de intercepción quedaría así encapsulada dentro del DSL, lejos del alcance de los desarrolladores
Esta entrada fue publicada en Software Architecture. Guarda el enlace permanente.

Una respuesta a AOP: por qué digo que el enfoque basado en Atributos no es serio

  1. Unknown dijo:

    creo que la confusión radica en aplicar la misma solución (los atributos) para implementar comportamiento declarativo y plugear aspectos.para mi los atributos son una excelente alternativa para implementar comportamiento declarativo…por e.g. los atributos transaccionales asociados a un método NO deben ser considerados aspectos, son lógica declarativa asociada directamente al método que condiciona implícitamente la forma de implementarlo…los verdaderos aspectos sin embargo son comportamiento completamente desacoplado del artefacto de software al cual son plugeados…para mi un ejemplo bien representativo de un aspecto es por e.g. Métricas…un aspecto de este tipo es bien cross-cotting y por lo tanto (tal cuál vos lo manifestas) debe ser expresado FUERA del código utilizando el lenguaje de point-cuts que nos brinde el framework de AOP que estemos utilizando.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s