Programación orientada a aspectos

En informática , la programación orientada a aspectos ( POA ) es un paradigma de programación que busca aumentar la modularidad al permitir la separación de las preocupaciones transversales . Lo hace agregando comportamiento al código existente (un consejo ) sin modificarlo, especificando en cambio qué código se modifica mediante una especificación de " punto de corte ", como "registrar todas las llamadas a funciones cuando el nombre de la función comience con 'set ' " . Esto permite agregar comportamientos que no son centrales para la lógica de negocio (como el registro) a un programa sin sobrecargar el código de las funciones principales.

La programación orientada a aspectos (AOP) incluye métodos y herramientas de programación que permiten la modularización de las funcionalidades a nivel del código fuente, mientras que el desarrollo de software orientado a aspectos se refiere a toda una disciplina de ingeniería.

La programación orientada a aspectos implica dividir la lógica del programa en áreas funcionales coherentes (denominadas preocupaciones ). Casi todos los paradigmas de programación admiten cierto grado de agrupación y encapsulación de preocupaciones en entidades separadas e independientes, proporcionando abstracciones (por ejemplo, funciones, procedimientos, módulos, clases, métodos) que pueden utilizarse para implementar, abstraer y componer dichas preocupaciones. Algunas preocupaciones "abarcan" varias abstracciones en un programa y desafían estas formas de implementación. Estas preocupaciones se denominan preocupaciones transversales u horizontales.

El registro de eventos ejemplifica una preocupación transversal, ya que una estrategia de registro debe afectar a cada parte del sistema que registra información. Por lo tanto, el registro afecta a todas las clases y métodos que registran información.

Todas las implementaciones de AOP cuentan con expresiones transversales que encapsulan cada aspecto en un solo lugar. La diferencia entre las implementaciones radica en la potencia, la seguridad y la usabilidad de las construcciones que proporcionan. Por ejemplo, los interceptores especifican los métodos para expresar una forma limitada de transversalidad, sin mucho soporte para la seguridad de tipos o la depuración. AspectJ dispone de varias de estas expresiones y las encapsula en una clase especial llamada aspecto . Por ejemplo, un aspecto puede modificar el comportamiento del código base (la parte del programa que no es un aspecto) aplicando consejos (comportamiento adicional) en varios puntos de unión (puntos en un programa) especificados en una cuantificación o consulta llamada punto de corte (que detecta si un punto de unión dado coincide). Un aspecto también puede realizar cambios estructurales compatibles binariamente en otras clases, como añadir miembros o padres.

AOP tiene varios antecedentes directos: ^{[ 1 ]} protocolos de reflexión y metaobjetos , programación orientada a sujetos , filtros de composición y programación adaptativa. ^{[ 2 ]}

Gregor Kiczales y sus colegas de Xerox PARC desarrollaron el concepto explícito de AOP y, posteriormente, crearon la extensión AspectJ AOP para Java. El equipo de investigación de IBM optó por un enfoque basado en herramientas en lugar de un enfoque de diseño de lenguaje y, en 2001, propuso Hyper/J y el Entorno de Manipulación de Preocupaciones , que no han tenido una amplia difusión.

Los ejemplos de este artículo utilizan AspectJ.

El Microsoft Transaction Server se considera la primera aplicación importante de AOP, seguida de Enterprise JavaBeans . ^{[ 3 ] [ 4 ]}

Por lo general, un aspecto se encuentra disperso o enredado en el código, lo que dificulta su comprensión y mantenimiento. Esta dispersión se produce cuando la función (como el registro de eventos) se distribuye entre varias funciones no relacionadas que podrían utilizarla , posiblemente en sistemas completamente distintos o escritas en lenguajes diferentes. Por lo tanto, modificar el registro de eventos puede requerir la modificación de todos los módulos afectados. Los aspectos se enredan no solo con la función principal de los sistemas en los que se expresan, sino también entre sí. Modificar un aspecto implica, por lo tanto, comprender todos los aspectos enredados o disponer de algún método para inferir el efecto de los cambios.

Por ejemplo, consideremos una aplicación bancaria con un método conceptualmente muy simple para transferir una cantidad de una cuenta a otra. Un ejemplo de este tipo en Java se vería así:

sealed class BankingException extends Exception permits InsufficientFundsException , UnauthorisedUserException { // ... }public class Bank { public void transfer ( Account fromAcc , Account toAcc , int amount ) throws BankingException { if ( fromAcc . getBalance () < amount ) { throw new InsufficientFundsException (); }fromAcc.retirar ( cantidad ) ; toAcc.depositar ( cantidad ) ; } }​​

Sin embargo, este método de transferencia pasa por alto ciertas consideraciones que requeriría una aplicación implementada, como verificar que el usuario actual esté autorizado para realizar esta operación, encapsular las transacciones de la base de datos para evitar la pérdida accidental de datos y registrar la operación con fines de diagnóstico.

Una versión que incluya todas esas nuevas preocupaciones podría verse así:

import java.util.logging.* ;sealed class BankingException extends Exception permits InsufficientFundsException , UnauthorisedUserException { // ... }public class Bank { private static final Logger logger ; private final Database database ; public void transfer ( Account fromAcc , Account toAcc , int amount , User user ) throws BankingException { logger . info ( "Transfiriendo dinero..." ); if ( ! isUserAuthorised ( user , fromAcc )) { logger . log ( Level . WARNING , "El usuario no tiene permiso." ); throw new UnauthorisedUserException (); } if ( fromAcc . getBalance () < amount ) { logger . log ( Level . WARNING , "Fondos insuficientes." ); throw new InsufficientFundsException (); }fromAcc.retirar ( cantidad ) ; toAcc.depositar ( cantidad ) ;​​base de datos.commitChanges ( ) ; // Operación atómica.registrador.registro ( Nivel.INFO , " Transacción exitosa . " ) ; } }

En este ejemplo, otros intereses se han entrelazado con la funcionalidad básica (a veces denominada lógica de negocio ). Las transacciones, la seguridad y el registro de eventos son ejemplos de preocupaciones transversales .

Ahora bien, ¿qué ocurriría si de repente tuviéramos que modificar las medidas de seguridad de la aplicación? En la versión actual del programa, las operaciones relacionadas con la seguridad aparecen dispersas en numerosos métodos, y tal cambio requeriría un gran esfuerzo.

AOP intenta resolver este problema permitiendo al programador expresar preocupaciones transversales en módulos independientes llamados aspectos . Los aspectos pueden contener consejos (código vinculado a puntos específicos del programa) y declaraciones entre tipos (miembros estructurales añadidos a otras clases). Por ejemplo, un módulo de seguridad puede incluir consejos que realicen una comprobación de seguridad antes de acceder a una cuenta bancaria. El punto de corte define los momentos ( puntos de unión ) en los que se puede acceder a una cuenta bancaria, y el código en el cuerpo del consejo define cómo se implementa la comprobación de seguridad. De esta forma, tanto la comprobación como los puntos de acceso se pueden mantener en un solo lugar. Además, un buen punto de corte puede anticipar cambios posteriores en el programa, de modo que si otro desarrollador crea un nuevo método para acceder a la cuenta bancaria, el consejo se aplicará al nuevo método cuando se ejecute.

Entonces, para el ejemplo anterior, implementando el registro en un aspecto:

aspecto Logger { Logger logger ;void Bank.transfer ( Account fromAcc , Account toAcc , int amount , User user ) { logger.info ( " Transfiriendo dinero ... " ) ; }void Bank.getMoneyBack ( User user , int transactionId ) { logger.info ( " El usuario solicitó la devolución del dinero." ) ; }// Otro código transversal. }

Se puede considerar la AOP como una herramienta de depuración o una herramienta de nivel de usuario. Los consejos deben reservarse para los casos en los que no se puede modificar la función (nivel de usuario) ^{[ 5 ]} o no se desea modificar la función en el código de producción (depuración).

El componente relacionado con el asesoramiento de un lenguaje orientado a aspectos define un modelo de punto de unión (JPM). Un JPM define tres cosas:

1. Cuando el consejo puede ejecutarse. Estos se denominan puntos de unión porque son puntos en un programa en ejecución donde se puede agregar comportamiento adicional de manera útil. Un punto de unión debe ser accesible y comprensible para un programador común para que sea útil. También debe ser estable ante cambios de programa insignificantes para mantener la estabilidad de los aspectos. Muchas implementaciones de AOP admiten ejecuciones de métodos y referencias de campos como puntos de unión.
2. Una forma de especificar (o cuantificar ) los puntos de unión, llamados puntos de corte . Los puntos de corte determinan si un punto de unión dado coincide. La mayoría de los lenguajes de puntos de corte útiles utilizan una sintaxis similar a la del lenguaje base (por ejemplo, AspectJ utiliza firmas de Java) y permiten la reutilización mediante la nomenclatura y la combinación.
3. Un método para especificar el código que se ejecutará en un punto de unión. AspectJ lo llama consejo y puede ejecutarlo antes, después y alrededor de los puntos de unión. Algunas implementaciones también admiten la definición de un método en un aspecto de otra clase.

Los modelos de puntos de unión se pueden comparar en función de los puntos de unión expuestos, cómo se especifican dichos puntos, las operaciones permitidas en ellos y las mejoras estructurales que se pueden expresar.

aspecto DisplayUpdate { void Point . acceptVisitor ( Visitor v ) { v . visit ( this ); } // otro código transversal... }

Los programas AOP pueden afectar a otros programas de dos maneras diferentes, dependiendo de los lenguajes y entornos subyacentes:

1. Se produce un programa combinado, válido en el idioma original e indistinguible de un programa ordinario para el intérprete final.
2. El intérprete o entorno definitivo se actualiza para comprender e implementar las características de AOP.

La dificultad de cambiar de entorno implica que la mayoría de las implementaciones generan programas de combinación compatibles mediante una transformación conocida como " tejido" . Un tejedor de aspectos lee el código orientado a aspectos y genera el código orientado a objetos apropiado con los aspectos integrados. Un mismo lenguaje AOP puede implementarse mediante diversos métodos de tejido, por lo que la semántica de un lenguaje nunca debe entenderse en función de la implementación del tejido. Solo la velocidad de la implementación y su facilidad de despliegue se ven afectadas por el método de combinación utilizado.

Los sistemas pueden implementar la interpolación a nivel de código fuente mediante preprocesadores (como se implementó originalmente en C++ con CFront ), que requieren acceso a los archivos fuente del programa. Sin embargo, la forma binaria bien definida de Java permite que los interpoladores de bytecode trabajen con cualquier programa Java en formato de archivo .class. Los interpoladores de bytecode pueden implementarse durante el proceso de compilación o, si el modelo de interpolación es por clase, durante la carga de clases. AspectJ comenzó con la interpolación a nivel de código fuente en 2001, ofreció un interpolador de bytecode por clase en 2002 y brindó soporte avanzado en tiempo de carga tras la integración de AspectWerkz en 2005.

Cualquier solución que combine programas en tiempo de ejecución debe proporcionar vistas que los separen adecuadamente para mantener el modelo segregado del programador. La compatibilidad de Java con el código de bytes para múltiples archivos fuente permite que cualquier depurador recorra paso a paso un archivo .class correctamente estructurado en un editor de código fuente. Sin embargo, algunos descompiladores de terceros no pueden procesar código estructurado porque esperan código producido por Javac en lugar de todas las formas de código de bytes compatibles (véase también la sección  Crítica , más adelante).

El tejido en tiempo de despliegue ofrece otro enfoque. ^{[ 6 ]} Esto implica básicamente un posprocesamiento, pero en lugar de parchear el código generado, este enfoque de tejido crea subclases de las clases existentes de modo que las modificaciones se introducen mediante la sobrescritura de métodos. Las clases existentes permanecen intactas, incluso en tiempo de ejecución, y todas las herramientas existentes, como depuradores y analizadores de rendimiento, pueden utilizarse durante el desarrollo. Un enfoque similar ya ha demostrado su eficacia en la implementación de muchos servidores de aplicaciones Java EE , como WebSphere de IBM .

Los aspectos surgieron de la programación orientada a objetos y la programación reflexiva . Los lenguajes AOP tienen una funcionalidad similar, pero más restringida, a la de los protocolos de metaobjetos . Los aspectos se relacionan estrechamente con conceptos de programación como sujetos , mixins y delegación . Otras formas de utilizar paradigmas de programación orientada a aspectos incluyen filtros de composición y el enfoque de hiperslices . Desde al menos la década de 1970, los desarrolladores han estado utilizando formas de intercepción y parcheo de despacho que se asemejan a algunos de los métodos de implementación para AOP, pero estos nunca tuvieron la semántica que las especificaciones transversales proporcionan en un solo lugar.

Los diseñadores han considerado formas alternativas de lograr la separación del código, como los tipos parciales de C# , pero estos enfoques carecen de un mecanismo de cuantificación que permita alcanzar varios puntos de unión del código con una sola instrucción declarativa.

Aunque pueda parecer irrelevante, en las pruebas, el uso de objetos simulados (mocks) o stubs requiere el uso de técnicas de AOP, como el análisis de referencia (around advice). En este caso, los objetos colaboradores son un aspecto transversal a la prueba. Por lo tanto, los distintos frameworks de objetos simulados ofrecen estas funcionalidades. Por ejemplo, un proceso invoca un servicio para obtener un saldo. En la prueba del proceso, no importa de dónde provenga el saldo, sino únicamente que el proceso lo utilice de acuerdo con los requisitos.

Los programadores necesitan poder leer y comprender el código para evitar errores. ^{[ 9 ]} Incluso con la formación adecuada, comprender las preocupaciones transversales puede resultar difícil sin el apoyo necesario para visualizar tanto la estructura estática como el flujo dinámico de un programa. ^{[ 10 ]} A partir de 2002, AspectJ comenzó a proporcionar complementos para IDE que facilitan la visualización de las preocupaciones transversales. Estas características, así como la asistencia de código de aspectos y la refactorización , son ahora comunes.

Dada la potencia de la PAO, un error lógico al expresar aspectos transversales puede provocar fallos generalizados en el programa. Por otro lado, otro programador podría modificar los puntos de unión del programa, por ejemplo, renombrando o moviendo métodos, de formas que el autor del aspecto no previó y con consecuencias imprevistas . Una ventaja de modularizar las preocupaciones transversales es que permite a un solo programador afectar fácilmente a todo el sistema. En consecuencia, estos problemas se manifiestan como un conflicto de responsabilidades entre dos o más desarrolladores ante un fallo determinado. La PAO puede agilizar la solución de estos problemas, ya que solo es necesario modificar el aspecto. Sin la PAO, los problemas correspondientes pueden estar mucho más dispersos.

La crítica más básica al efecto de AOP es que el flujo de control se oscurece, y que no solo es peor que la tan criticada instrucción GOTO , sino que es muy similar a la instrucción COME FROM , que es una broma . ^{[ 10 ]} La falta de conocimiento de la aplicación , que es fundamental para muchas definiciones de AOP (el código en cuestión no tiene ninguna indicación de que se aplicará un consejo, que se especifica en cambio en el punto de corte), significa que el consejo no es visible, a diferencia de una llamada a un método explícito. ^{[ 10 ] [ 11 ]} Por ejemplo, compárese el programa COME FROM: ^{[ 10 ]}

5 ENTRADA X 10 IMPRIMIR 'El resultado es:' 15 IMPRIMIR X 20 PROVIENE DE 10 25 X = X * X 30 RETORNAR

con un fragmento AOP con semántica análoga:

main () { input x print ( resultado ( x )) }input result ( int x ) { return x } around ( int x ): call ( result ( int )) && args ( x ) { int temp = proceed ( x ) return temp * temp }

De hecho, el punto de corte puede depender de las condiciones de ejecución y, por lo tanto, no ser estáticamente determinista. Esto se puede mitigar, pero no solucionar, mediante análisis estáticos y el soporte del IDE, que muestra qué consejos coinciden potencialmente .

Las críticas generales señalan que la AOP pretende mejorar tanto la modularidad como la estructura del código, pero algunos argumentan que, en cambio, socava estos objetivos e impide el desarrollo independiente y la comprensibilidad de los programas. ^{[ 12 ]} Específicamente, la cuantificación mediante puntos de corte rompe la modularidad: «en general, se debe tener conocimiento del programa completo para razonar sobre la ejecución dinámica de un programa orientado a aspectos». ^{[ 13 ]} Además, si bien sus objetivos (modularizar las preocupaciones transversales) se comprenden bien, su definición real no es clara y no se distingue claramente de otras técnicas bien establecidas. ^{[ 12 ]} Las preocupaciones transversales pueden intersecarse entre sí, lo que requiere algún mecanismo de resolución, como el ordenamiento. ^{[ 12 ]} De hecho, los aspectos pueden aplicarse a sí mismos, lo que lleva a problemas como la paradoja del mentiroso . ^{[ 14 ]}

Las críticas técnicas incluyen que la cuantificación de los puntos de corte (que definen dónde se ejecutan los consejos) es "extremadamente sensible a los cambios en el programa", lo que se conoce como el problema de los puntos de corte frágiles . ^{[ 12 ]} Los problemas con los puntos de corte se consideran intratables. Si se reemplaza la cuantificación de los puntos de corte con anotaciones explícitas, se obtiene programación orientada a atributos , que es simplemente una llamada explícita a una subrutina y sufre el mismo problema de dispersión, que la POA fue diseñada para resolver. ^{[ 12 ]}

Muchos lenguajes de programación han implementado AOP, ya sea dentro del propio lenguaje o como una biblioteca externa , entre ellos:

• Lenguajes del framework .NET ( C# , Visual Basic (.NET) (VB.NET)) ^{[ 15 ]}
  • PostSharp es una implementación comercial de AOP con una edición gratuita pero limitada.
  • Unity proporciona una API para facilitar prácticas probadas en áreas clave de la programación, como el acceso a datos, la seguridad, el registro de eventos, el manejo de excepciones y otras.
  • AspectDN es una implementación de AOP que permite integrar los aspectos directamente en los archivos ejecutables de .NET.
• ActionScript ^{[ 16 ]}
• Ada ^{[ 17 ]}
• AutoHotkey ^{[ 18 ]}
• C , C++ ^{[ 19 ]}
• COBOL ^{[ 20 ]}
• Los marcos de trabajo Cocoa Objective-C ^{[ 21 ]}
• ColdFusion ^{[ 22 ]}
• Lisp común ^{[ 23 ]}
• Delfos ^{[ 24 ] [ 25 ] [ 26 ]}
• Prisma de Delfos ^{[ 27 ]}
• e (IEEE 1647)
• Emacs Lisp ^{[ 28 ]}
• Genial
• Haskell ^{[ 29 ]}
• Java ^{[ 30 ]}
  • AspectoJ
• JavaScript ^{[ 31 ]}
• Logtalk ^{[ 32 ]}
• Lua ^{[ 33 ]}
• hacer ^{[ 34 ]}
• Matlab ^{[ 35 ]}
• ML ^{[ 36 ]}
• Nemerle ^{[ 37 ]}
• Perl ^{[ 38 ]}
• PHP ^{[ 39 ]}
• Prólogo ^{[ 40 ]}
• Python ^{[ 41 ]}
• Raqueta ^{[ 42 ]}
• Rubí ^{[ 43 ] [ 44 ] [ 45 ]}
• Chirrido Charla pequeña ^{[ 46 ] [ 47 ]}
• UML 2.0 ^{[ 48 ]}
• XML ^{[ 49 ]}

• AOP distribuido
• Gramática de atributos , un formalismo que puede utilizarse para la programación orientada a aspectos en lenguajes de programación funcional .
• paradigmas de programación
• Programación orientada a sujetos , una alternativa a la programación orientada a aspectos.
• Programación orientada a roles , una alternativa a la programación orientada a aspectos.
• Despacho de predicados , una alternativa más antigua a la programación orientada a aspectos.
• UML ejecutable
• Patrón decorativo
• Diseño orientado al dominio

• Kiczales, G.; Lamping, J.; Mendhekar, A.; Maeda, C.; Lopes, C.; Loingtier, JM; Irwin, J. (1997). Programación orientada a aspectos (PDF) . ECOOP'97. Actas de la 11.ª Conferencia Europea sobre Programación Orientada a Objetos . Lecture Notes in Computer Science (LNCS). Vol.  1241. pp. 220–242 . CiteSeerX 10.1.1.115.8660 . doi : 10.1007/BFb0053381 . ISBN   3-540-63089-9.El artículo generalmente considerado como la referencia autorizada para AOP.
• Robert E. Filman; Tzilla Elrad; Siobhán Clarke ; Mehmet Aksit (2004). Desarrollo de software orientado a aspectos . Addison-Wesley. ISBN 978-0-321-21976-3.
• Renaud Pawlak, Lionel Seinturier y Jean-Philippe Retaillé (2005). Fundamentos de AOP para el desarrollo de J2EE . Apress. ISBN 978-1-59059-507-7.
• Laddad, Ramnivas (2003). AspectJ en acción: Programación práctica orientada a aspectos . Manning. ISBN 978-1-930110-93-9.
• Jacobson, Ivar ; Pan-Wei Ng (2005). Desarrollo de software orientado a aspectos con casos de uso . Addison-Wesley. ISBN 978-0-321-26888-4.
• Desarrollo de software orientado a aspectos y PHP, Dmitry Sheiko, 2006
• Siobhán Clarke y Elisa Baniassad (2005). Análisis y diseño orientados a aspectos: El enfoque temático . Addison-Wesley. ISBN 978-0-321-24674-5.
• Raghu Yedduladoddi (2009). Desarrollo de software orientado a aspectos: un enfoque para la composición de modelos de diseño UML . VDM. ISBN 978-3-639-12084-4.
• "Programación adaptativa orientada a objetos mediante personalización basada en grafos" – Lieberherr, Silva-Lepe, et al. – 1994
• Zambrano Polo y La Borda, Arturo Federico (5 de junio de 2013). "Abordando las interacciones de aspectos en un entorno industrial: experiencias, problemas y soluciones" : 159. doi : 10.35537/10915/35861 . Recuperado el 30 de mayo de 2014 .{{cite journal}}: Para citar una revista se requiere |journal=( ayuda )
• Wijesuriya, Viraj Brian (30 de agosto de 2016) Desarrollo orientado a aspectos, Apuntes de clase, Facultad de Informática de la Universidad de Colombo, Sri Lanka
• Groves, Matthew D. (2013). AOP en .NET . Manning. ISBN 9781617291142.

• Lista de herramientas AOP de Eric Bodden en el framework .NET
• Desarrollo de software orientado a aspectos , conferencia anual sobre AOP
• Guía de programación de AspectJ
• El compilador AspectBench para AspectJ , otra implementación de Java.
• Serie de artículos de IBM developerWorks sobre AOP
• Laddad, Ramnivas (18 de enero de 2002). "¡Quiero mi AOP!, Parte 1" . Mundo Java . Consultado el 20 de julio de 2020 .Una serie detallada de artículos sobre los fundamentos de la programación orientada a aspectos y AspectJ.
• ¿Qué es la programación orientada a aspectos? , introducción con RemObjects Taco
• Tejedor de aspectos de especificación de restricciones
• Programación orientada a aspectos frente a programación orientada a objetos: ¿Qué técnica usar y cuándo? Archivado el 15 de abril de 2021 en Wayback Machine.
• Gregor Kiczales, profesor de informática, explicando la programación orientada a aspectos (AOP) , vídeo de 57 minutos.
• Programación orientada a aspectos en COBOL. Archivado el 17 de diciembre de 2008 en Wayback Machine.
• Programación orientada a aspectos en Java con Spring Framework
• Wiki dedicada a los métodos AOP en .NET
• Aspectos iniciales para el modelado de procesos de negocio (un lenguaje orientado a aspectos para BPMN)
• Introducción a Spring AOP y AspectJ
• Curso de posgrado de AOSD en la Universidad de Bilkent
• Introducción a la programación orientada a aspectos (AOP) – Episodio 106 del podcast de ingeniería de software
• Una implementación Objective-C de AOP por Szilveszter Molnar
• Programación orientada a aspectos para iOS y OS X por Manuel Gebele
• Framework DevExpress MVVM. Introducción a los ViewModels POCO.