Programación orientada a aspectos

A Programación Orientada a Aspectos (POA) é un paradigma de programación relativamente recente cuxa intención é permitir unha adecuada modularización das aplicacións e posibilitar unha mellor separación de conceptos. Grazas á POA pódense encapsular os diferentes conceptos que compón unha aplicación en entidades ben definidas, eliminando as dependencias entre cada un dos módulos. Desta forma conséguese razoar mellor sobre os conceptos, elimínase a dispersión do código e as implementaciones resultan máis comprensibles, adaptables e reusables. Varias tecnoloxías con nomes diferentes encamíñanse á consecución dos mesmos obxectivos e así, o termo POA é usado para referirse a varias tecnoloxías relacionadas como os métodos adaptivos, os filtros de composición, a programación orientada a suxeitos ou a separación multidimensional de competencias

Objectivo

O principal obxectivo da POA é a separación das funcionalidades dentro do sistema:

Por unha banda funcionalidades comúns utilizadas ao longo da aplicación
Doutra banda, as funcionalidades propias de cada módulo.

Cada funcionalidade común encapsularase nunha entidade.

Conceptos Básicos

Debido á escasa literatura en español, preséntase a terminoloxía orixinal en inglés.

Aspect (Aspecto) é a funcionalidade que se cruza ao longo da aplicación (cros-cutting) que se vai a implementar de forma modular e separada do resto do sistema. O exemplo máis común e simple dun aspecto é o loggin (rexistro de sucesos) dentro do sistema, xa que necesariamente afecta a todas as partes do sistema que xeran un suceso.
Jointpoint (Punto de Cruzamento) é un punto de execución dentro do sistema onde un aspecto pode ser conectado, como unha chamada a un método, o lanzamento dunha excepción ou a modificación dun campo. O código do aspecto será inserido no fluxo de execución da aplicación para engadir a súa funcionalidade.
Advice (Consello) é a implementación do aspecto, é dicir, contén o código que implementa a nova funcionalidade. Insérense na apliacción nos Puntos de Cruzamento.
Pointcut (Puntos de Corte) define os Consellos que se aplicarán a cada Punto de Cruzamento. Especifícase mediante Expresións Regulares ou mediante patróns de nomes (de clases, métodos ou campos), e ata dinámicamente en tempo de execución segundo o valor de certos parámetros.
Introduction (Introdución) permite engadir métodos ou atributos a clases xa existentes. Un exemplo no que resultaría útil é a creación dun Consello de Auditoría que manteña a data da última modificación dun obxecto, mediante unha variable e un método setUltimaModificacion(data), que poderían ser introducidos en todas as clases (ou só nalgunhas) para proporcionalas esta nova funionalidad.
Target (Destinatario) é a clase aconsellada, a clase que é obxecto dun consello. Sen AOP, esta clase debería de contenter a súa lóxica, ademais da lóxica do aspecto.
Proxy (Resultante) é o obxecto creado logo de aplicar o Consello ao Obxecto Destinatario. O resto da aplicación unicamente terá que soportar ao Obxecto Destinatario (pre-AOP) e non ao Obxecto Resultante (post-AOP)
Weaving é o proceso de aplicar Aspectos aos Obxectos Destinatarios para crear os novos Obxectos Resultantes nos especificados Puntos de Cruzamento. Este proceso pode ocorrer ao longo do ciclo de vida do Obxecto Destinatario:
- Aspectos en tempo de Compilación, que necesita un compilador especial.
- Aspectos en tempo de Carga, os Aspectos se implementan cando o Obxecto Destinatario é cargado na JVM. Require un ClassLoader especial.
- Aspectos en tempo de Execución.

Problemas doutros paradigmas

Moitas veces atopámonos, á hora de programar, con problemas que non podemos resolver dun xeito adecuado coas técnicas habituais usadas na programación imperativa ou na programación orientada a obxectos. Con estas, vémonos forzados a tomar decisións de deseño que repercuten de xeito importante no desenvolvemento da aplicación e que nos afastan con frecuencia doutras posibilidades.

Doutra banda, a implementación de devanditas decisións a miúdo implica escribir liñas de código que están distribuídas por toda, ou gran parte, da aplicación para definir a lóxica de certa propiedade ou comportamento do sistema, coas consecuentes dificultades de mantemento e desenvolvemento que iso implica. En inglés este problema coñécese como scattered code, que poderiamos traducir como código disperso. Outro problema que pode aparecer é que un mesmo módulo se implemente de modo que manexe múltiples comportamentos ou aspectos do sistema simultaneamente. En inglés este problema coñécese como tangled code, que poderiamos traducir como código enmarañado. O feito é que hai certas decisións de deseño que son difíciles de capturar coas técnicas antes citadas, debéndose ao feito de que certos problemas non se deixan encapsular de igual forma que os que habitualmente se resolveron con funcións ou obxectos. A resolución destes supón ou ben a utilización de repetidas liñas de código por diferentes compoñentes do sistema, ou ben a superposición dentro dun compoñente de funcionalidades dispares.

Programación orientada a obxectos

A programación orientada a obxectos (POO) supuxo un gran paso na enxeñería do software, xa que presentaba un modelo de obxectos que parecía encaixar de xeito adecuado cos problemas reais. A cuestión era saber descompor do mellor xeito o dominio do problema ao que nos enfrontásemos, encapsulando cada concepto no que se deu en chamar obxectos e facéndolles interactuar entre eles, habéndolles dotado dunha serie de propiedades.

Xurdiron así numerosas metodoloxías para axudar en tal proceso de descomposición e apareceron ferramentas que ata automatizaban parte do proceso. Isto non cambiou e séguese facendo no proceso de desenvolvemento do software. Con todo, frecuentemente a relación entre a complexidade da solución e o problema resolto fai pensar na necesidade dun novo cambio. Así pois, atopámonos con moitos problemas onde a POO non é suficiente para capturar dun xeito claro todas as propiedades e comportamentos dos que queremos dotar á nosa aplicación. Así mesmo, a programación imperativa tampouco nos soluciona o problema.