stringtranslate.com

Programación Orientada a Aspectos

En informática , la programación orientada a aspectos ( AOP ) es un paradigma de programación que tiene como objetivo aumentar la modularidad al permitir la separación de preocupaciones transversales . Lo hace agregando comportamiento al código existente (un consejo ) sin modificar el código, en lugar de especificar por separado qué código se modifica mediante una especificación " pointcut ", como "registrar todas las llamadas a funciones cuando el nombre de la función comienza con 'set ' ". Esto permite agregar a un programa comportamientos que no son centrales para la lógica empresarial (como el registro) sin saturar el código de funciones principales.

AOP incluye métodos y herramientas de programación que respaldan la modularización de preocupaciones 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 coherentes de funcionalidad (las llamadas preocupaciones ). Casi todos los paradigmas de programación admiten algún nivel de agrupación y encapsulación de preocupaciones en entidades separadas e independientes al proporcionar abstracciones (por ejemplo, funciones, procedimientos, módulos, clases, métodos) que pueden usarse para implementar, abstraer y componer estas preocupaciones. Algunas preocupaciones "atraviesan" múltiples abstracciones en un programa y desafían estas formas de implementación. Estas preocupaciones se denominan preocupaciones transversales o preocupaciones horizontales.

El registro ejemplifica una preocupación transversal porque una estrategia de registro debe afectar a cada parte registrada del sistema. De este modo, el registro abarca todas las clases y métodos registrados.

Todas las implementaciones de AOP tienen algunas expresiones transversales que encapsulan cada preocupación en un solo lugar. La diferencia entre implementaciones radica en la potencia, la seguridad y la usabilidad de las construcciones proporcionadas. Por ejemplo, interceptores que especifican los métodos para expresar una forma limitada de corte transversal, sin mucho soporte para la seguridad de tipos o la depuración. AspectJ tiene varias expresiones de este tipo y las encapsula en una clase especial, llamada aspecto . Por ejemplo, un aspecto puede alterar el comportamiento del código base (la parte de un 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 determinado coincide). Un aspecto también puede realizar cambios estructurales compatibles con binarios en otras clases, como agregar miembros o padres.

Historia

AOP tiene varios antecedentes directos A1 y A2: [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 lo siguieron con la extensión AspectJ AOP para Java. El equipo de investigación de IBM siguió un enfoque de herramienta en lugar de un enfoque de diseño de lenguaje y en 2001 propuso Hyper/J y Concern Manipulation Environment , que no han tenido un uso generalizado.

Los ejemplos de este artículo utilizan AspectJ.

Se considera que Microsoft Transaction Server es la primera aplicación importante de AOP, seguida de Enterprise JavaBeans . [3] [4]

Motivación y conceptos básicos.

Normalmente, un aspecto está disperso o enredado como código, lo que dificulta su comprensión y mantenimiento. Está disperso porque la función (como el registro) se distribuye entre una serie de funciones no relacionadas que podrían usar su función, posiblemente en sistemas completamente no relacionados o escritos en diferentes idiomas. Por lo tanto, cambiar el registro puede requerir modificar todos los módulos afectados. Los aspectos se enredan no sólo con la función principal de los sistemas en los que se expresan, sino también entre sí. Por lo tanto, cambiar una preocupación implica comprender todas las preocupaciones enredadas o tener algún medio por el cual se pueda inferir el efecto de los cambios.

Por ejemplo, considere una aplicación bancaria con un método conceptualmente muy simple para transferir una cantidad de una cuenta a otra: [5]

anular la transferencia ( Cuenta de Cuenta , Cuenta a Cuenta , monto int ) arroja una excepción { si ( de Cuenta . getSaldo () < cantidad ) lanza una nueva InsufficientFundsException ();                 de Acc . retirar ( cantidad ); a Acc . cantidad del depósito ) ; }

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 con todas esas nuevas preocupaciones podría verse así:

anular la transferencia ( Cuenta de Acc , Cuenta a Acc , monto int , Usuario usuario , Registrador , Base de datos ) arroja una excepción { logger . info ( "Transfiriendo dinero..." ); if ( ! isUserAuthorised ( usuario , fromAcc )) { registrador . info ( "El usuario no tiene permiso." ); lanzar una nueva excepción de usuario no autorizada (); } if ( fromAcc . getBalance () < monto ) { registrador . info ( "Fondos insuficientes." ); lanzar una nueva InsufficientFundsException (); }                                      de Acc . retirar ( cantidad ); a Acc . cantidad del depósito ) ;  base de datos . Cometer cambios (); // Operación atómica.  registrador . info ( "Transacción exitosa." ); }

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

Ahora considere lo que sucedería si de repente tuviéramos que cambiar las consideraciones 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 inquietudes transversales en módulos independientes llamados aspectos . Los aspectos pueden contener consejos (código unido a puntos específicos del programa) y declaraciones entre tipos (miembros estructurales agregados a otras clases). Por ejemplo, un módulo de seguridad puede incluir consejos que realicen un control 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 de aviso define cómo se implementa el control de seguridad. De esta manera, tanto el cheque como las plazas se pueden mantener en un solo lugar. Además, un buen pointcut puede anticipar cambios posteriores en el programa, por lo 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 que implementa el registro en un aspecto:

aspecto Registrador { void Bank . transferir ( Cuenta de Acc , Cuenta a Acc , monto int , Usuario usuario , Registrador registrador ) { registrador . info ( "Transfiriendo dinero..." ); }                 Banco nulo . getMoneyBack ( Usuario usuario , int ID de transacción , registrador registrador ) { registrador . info ( "El usuario solicitó la devolución del dinero." ); }          // Otro código transversal. }

Se puede pensar en AOP como una herramienta de depuración o una herramienta a nivel de usuario. Se deben reservar consejos para los casos en los que no se puede cambiar la función (nivel de usuario) [6] o no se desea cambiar la función en el código de producción (depuración).

Unir modelos de puntos

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

  1. Cuándo se puede ejecutar el consejo. Estos se denominan puntos de unión porque son puntos en un programa en ejecución donde se pueden unir de manera útil comportamientos adicionales. 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 intrascendentes para mantener la estabilidad del aspecto. 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 ) puntos de unión, llamados puntos de corte . Los puntos de corte determinan si un punto de unión determinado coincide. Los lenguajes de corte de punto más útiles utilizan una sintaxis similar al lenguaje base (por ejemplo, AspectJ usa firmas Java) y permiten la reutilización mediante nombres y combinaciones.
  3. Un medio para especificar el código que se ejecutará en un punto de unión. AspectJ llama a este 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 los puntos de unión, las operaciones permitidas en los puntos de unión y las mejoras estructurales que se pueden expresar.

Modelo de punto de unión de AspectJ

Otros posibles modelos de puntos de unión

Hay otros tipos de JPM. Todos los idiomas de asesoramiento se pueden definir en términos de su JPM. Por ejemplo, un lenguaje de aspecto hipotético para UML puede tener el siguiente JPM:

Declaraciones entre tipos

Las declaraciones entre tipos proporcionan una manera de expresar preocupaciones transversales que afectan la estructura de los módulos. También conocido como clases abiertas y métodos de extensión , esto permite a los programadores declarar en un lugar miembros o padres de otra clase, generalmente para combinar todo el código relacionado con una preocupación en un aspecto. Por ejemplo, si un programador implementó la preocupación transversal de actualización de visualización usando visitantes, una declaración entre tipos usando el patrón de visitante podría verse así en AspectJ:

 aspecto DisplayUpdate { punto vacío . aceptarVisitante ( Visitante v ) { v . visitar ( esto ); } // otro código transversal... }

Este fragmento de código agrega el acceptVisitormétodo a la Pointclase.

Se requiere que cualquier adición estructural sea compatible con la clase original, de modo que los clientes de la clase existente continúen operando, a menos que la implementación de AOP pueda esperar controlar a todos los clientes en todo momento.

Implementación

Los programas AOP pueden afectar a otros programas de dos maneras diferentes, según 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 funciones de AOP.

La dificultad de cambiar entornos significa que la mayoría de las implementaciones producen programas combinados compatibles a través de un tipo de transformación de programa conocido como tejido . Un tejedor de aspectos lee el código orientado a aspectos y genera código orientado a objetos apropiado con los aspectos integrados. El mismo lenguaje AOP se puede implementar mediante una variedad de métodos de tejido, por lo que la semántica de un lenguaje nunca debe entenderse en términos de la implementación del tejido. Sólo la velocidad de una implementación y su facilidad de implementación se ven afectadas por el método de combinación utilizado.

Los sistemas pueden implementar el tejido a nivel de fuente utilizando preprocesadores (como C++ se implementó originalmente en CFront ) que requieren acceso a los archivos fuente del programa. Sin embargo, la forma binaria bien definida de Java permite a los tejedores de códigos de bytes trabajar con cualquier programa Java en formato de archivo .class. Los tejedores de código de bytes se pueden implementar durante el proceso de construcción o, si el modelo de tejido es por clase, durante la carga de clases. AspectJ comenzó con el tejido a nivel de fuente en 2001, entregó un tejedor de código de bytes por clase en 2002 y ofreció soporte avanzado de tiempo de carga después de la integración de AspectWerkz en 2005.

Cualquier solución que combine programas en tiempo de ejecución debe proporcionar vistas que los segreguen adecuadamente para mantener el modelo segregado del programador. El soporte de código de bytes de Java para múltiples archivos fuente permite que cualquier depurador recorra un archivo .class correctamente tejido en un editor de código fuente. Sin embargo, algunos descompiladores de terceros no pueden procesar código tejido porque esperan código producido por Javac en lugar de todas las formas de código de bytes admitidas (consulte también § Crítica, a continuación).

El tejido en tiempo de implementación ofrece otro enfoque. [7] Esto básicamente implica un posprocesamiento, pero en lugar de parchear el código generado, este enfoque de tejido crea subclases de clases existentes para que las modificaciones se introduzcan mediante la anulación de métodos. Las clases existentes permanecen intactas, incluso en tiempo de ejecución, y todas las herramientas existentes, como depuradores y generadores de perfiles, se pueden utilizar durante el desarrollo. Un enfoque similar ya ha demostrado su eficacia en la implementación de muchos servidores de aplicaciones Java EE , como por ejemplo WebSphere de IBM .

Terminología

La terminología estándar utilizada en la programación orientada a aspectos puede incluir:

Preocupaciones transversales
Aunque la mayoría de las clases en un modelo orientado a objetos realizarán una función única y específica, a menudo comparten requisitos secundarios comunes con otras clases. Por ejemplo, es posible que deseemos agregar registros a las clases dentro de la capa de acceso a datos y también a las clases en la capa UI cada vez que un hilo ingresa o sale de un método. Otras preocupaciones pueden estar relacionadas con la seguridad, como el control de acceso [8] o el control del flujo de información . [9] Aunque cada clase tiene una funcionalidad primaria muy diferente, el código necesario para realizar la funcionalidad secundaria suele ser idéntico.
Consejo
Este es el código adicional que desea aplicar a su modelo existente. En nuestro ejemplo, este es el código de registro que queremos aplicar cada vez que el hilo entra o sale de un método:
corte puntual
Esto se refiere al punto de ejecución de la aplicación en el que se debe aplicar la preocupación transversal. En nuestro ejemplo, se alcanza un punto de corte cuando el hilo ingresa a un método y se alcanza otro punto de corte cuando el hilo sale del método.
Aspecto
La combinación del pointcut y el consejo se denomina aspecto. En el ejemplo anterior, agregamos un aspecto de registro a nuestra aplicación definiendo un punto de acceso y brindando el consejo correcto.

Comparación con otros paradigmas de programación

Aspectos surgidos de la programación orientada a objetos y la programación reflexiva . Los lenguajes AOP tienen una funcionalidad similar a la de los protocolos de metaobjetos , pero más restringida . Los aspectos se relacionan estrechamente con conceptos de programación como temas , 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 interceptación y distribución de parches que se asemejan a algunos de los métodos de implementación de AOP, pero nunca tuvieron la semántica que las especificaciones transversales proporcionan en un solo lugar. [ cita necesaria ]

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

Aunque pueda parecer no relacionado, en las pruebas, el uso de simulacros o stubs requiere el uso de técnicas de AOP, como consejos generales. Aquí los objetos colaboradores son, a efectos de la prueba, una preocupación transversal. Por lo tanto, los diversos marcos de objetos simulados proporcionan estas características. Por ejemplo, un proceso invoca un servicio para obtener un saldo. En la prueba del proceso, no importa de dónde proviene el monto, sino sólo que el proceso utilice el saldo de acuerdo con los requisitos. [ cita necesaria ]

Problemas de adopción

Los programadores deben poder leer y comprender el código para evitar errores. [10] Incluso con una educación adecuada, comprender las preocupaciones transversales puede resultar difícil sin el apoyo adecuado para visualizar tanto la estructura estática como el flujo dinámico de un programa. [11] A partir de 2002, AspectJ comenzó a proporcionar complementos IDE para respaldar la visualización de inquietudes transversales. Esas características, así como la asistencia de código de aspecto y la refactorización , ahora son comunes.

Dado el poder del POA, cometer un error lógico al expresar la transversalidad puede llevar al fracaso generalizado del programa. Por el contrario, otro programador puede cambiar los puntos de unión en un programa, como cambiando el nombre o moviendo métodos, de maneras que el autor del aspecto no anticipó y con consecuencias imprevistas . Una ventaja de modularizar las preocupaciones transversales es permitir que un programador afecte fácilmente a todo el sistema. Como resultado, estos problemas se manifiestan como un conflicto sobre la responsabilidad entre dos o más desarrolladores por un fallo determinado. AOP puede acelerar la solución de estos problemas, ya que sólo se debe cambiar el aspecto. Sin AOP, los problemas correspondientes pueden estar mucho más extendidos. [ cita necesaria ]

Crítica

La crítica más básica al efecto de AOP es que el flujo de control está oscurecido y que no sólo es peor que la tan difamada declaración GOTO , sino que es muy similar a la declaración en broma COME FROM . [11] El olvido 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 en cambio se especifica en el punto), significa que el consejo no es visible, en contraste a una llamada a un método explícito. [11] [12] Por ejemplo, compare el programa COME FROM: [11]

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

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

principal () { entrada x imprimir ( resultado ( x )) } entrada resultado ( int x ) { retorno x } alrededor ( int x ): llamada ( resultado ( int )) && args ( x ) { int temp = continuar ( x ) temperatura de retorno * temperatura }

De hecho, el punto de corte puede depender de la condición del tiempo de ejecución y, por lo tanto, no ser estáticamente determinista. Esto se puede mitigar, pero no resolver, mediante un análisis estático y soporte IDE que muestre qué consejos potencialmente coinciden.

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

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 frágil de los puntos de corte . [13] Los problemas con los pointcuts se consideran intratables. Si se reemplaza la cuantificación de puntos de corte con anotaciones explícitas, se obtiene programación orientada a atributos , que es simplemente una llamada explícita a subrutina y sufre el mismo problema de dispersión, para el cual AOP fue diseñado. [13]

Implementaciones

Muchos lenguajes de programación han implementado AOP, dentro del lenguaje o como una biblioteca externa , incluidos:

Ver también

notas y referencias

  1. ^ Kiczales, G .; Lamping, J.; Mendhekar, A.; Maeda, C.; López, C.; Loingtier, JM; Irwin, J. (1997). Programación orientada a aspectos (PDF) . Ecoop '97. Actas de la XI Conferencia Europea sobre Programación Orientada a Objetos . Apuntes de conferencias en informática (LNCS). vol. 1241, págs. 220–242. CiteSeerX  10.1.1.115.8660 . doi :10.1007/BFb0053381. ISBN 3-540-63089-9. Archivado (PDF) desde el original el 12 de enero de 2016.
  2. ^ "Programación adaptativa orientada a objetos: el enfoque de Demeter con patrones de propagación" Karl Liebherr 1996 ISBN 0-534-94602-X presenta una versión bien trabajada de esencialmente lo mismo (Lieberherr posteriormente reconoció esto y reformuló su enfoque). 
  3. ^ Don Caja; Chris Sells (4 de noviembre de 2002). Essential.NET: el tiempo de ejecución de lenguaje común . Profesional de Addison-Wesley. pag. 206.ISBN​ 978-0-201-73411-9. Consultado el 4 de octubre de 2011 .
  4. ^ Romano, Ed; Sriganesh, Rima Patel; Brose, Gerald (1 de enero de 2005). Dominar los JavaBeans empresariales. John Wiley e hijos. pag. 285.ISBN​ 978-0-7645-8492-3. Consultado el 4 de octubre de 2011 .
  5. ^ Nota: Los ejemplos de este artículo aparecen en una sintaxis similar a la del lenguaje Java .
  6. ^ "gnu.org". Proyecto GNU. Archivado desde el original el 24 de diciembre de 2017 . Consultado el 5 de mayo de 2018 .
  7. ^ "Copia archivada" (PDF) . Archivado desde el original (PDF) el 8 de octubre de 2005 . Consultado el 19 de junio de 2005 .{{cite web}}: Mantenimiento CS1: copia archivada como título ( enlace )
  8. ^ B. De Win, B. Vanhaute y B. De Decker. "Seguridad a través de programación orientada a aspectos". En Avances en seguridad de redes y sistemas distribuidos (2002).
  9. ^ T. Pasquier, J. Bacon y B. Shand. "FlowR: programación orientada a aspectos para el control del flujo de información en Ruby". En Actas ACM de la 13ª conferencia internacional sobre modularidad (desarrollo de software orientado a aspectos) (2014).
  10. ^ Edsger Dijkstra , Notas sobre programación estructurada Archivado el 12 de octubre de 2006 en Wayback Machine , pág. 1-2
  11. ^ abcd Constantinides, Constantinos; Skotiniotis, Therapon; Störzer, Maximilian (septiembre de 2004). AOP considerado nocivo (PDF) . Taller interactivo europeo sobre aspectos del software (EIWAS). Berlín, Alemania. Archivado (PDF) desde el original el 23 de marzo de 2016 . Consultado el 5 de mayo de 2018 .
  12. ^ C2: Venir de
  13. ^ abcde Steimann, F. (2006). "El éxito paradójico de la programación orientada a aspectos". Avisos ACM SIGPLAN . 41 (10): 481–497. CiteSeerX 10.1.1.457.2210 . doi :10.1145/1167515.1167514. , (diapositivas Archivadas el 4 de marzo de 2016 en Wayback Machine , diapositivas 2 Archivadas el 23 de septiembre de 2015 en Wayback Machine , resumen Archivado el 24 de septiembre de 2015 en Wayback Machine ), Friedrich Steimann, Gary T. Leavens, OOPSLA 2006
  14. ^ "Más razonamiento modular para programas orientados a aspectos". Archivado desde el original el 12 de agosto de 2015 . Consultado el 11 de agosto de 2015 .
  15. ^ "AOP y la antinomia del mentiroso" (PDF) . fernuni-hagen.de . Archivado (PDF) desde el original el 9 de agosto de 2017 . Consultado el 5 de mayo de 2018 .
  16. ^ Numerosos: ocurrencia tardía Archivado el 15 de marzo de 2016 en Wayback Machine , LOOM.NET Archivado el 27 de agosto de 2008 en Wayback Machine , bloque de aplicación de inyección de políticas Enterprise Library 3.0 Archivado el 19 de enero de 2007 en Wayback Machine , AspectDNG Archivado en 2004 -29 de septiembre en Wayback Machine , DynamicProxy Archivado el 5 de diciembre de 2015 en Wayback Machine , Compose* Archivado el 21 de agosto de 2005 en Wikiwix, PostSharp Archivado el 3 de mayo de 2016 en Wayback Machine , Seasar.NET Archivado en 2006- 25-07 en Wayback Machine , DotSpect (.SPECT) Archivado el 31 de marzo de 2006 en Wayback Machine , Spring.NET Archivado el 2 de abril de 2006 en Wayback Machine (como parte de su funcionalidad), Wicca y Phx.Morph Archivado el 7 de diciembre de 2006 en Wayback Machine , SetPoint Archivado el 7 de octubre de 2008 en Wayback Machine.
  17. ^ "Bienvenido a as3-commons-bytecode". as3commons.org . Archivado desde el original el 3 de octubre de 2014 . Consultado el 5 de mayo de 2018 .
  18. ^ "Justificación de Ada2012" (PDF) . adacore.com . Archivado (PDF) desde el original el 18 de abril de 2016 . Consultado el 5 de mayo de 2018 .
  19. ^ "Ganchos de funciones". autohotkey.com . Archivado desde el original el 17 de enero de 2013 . Consultado el 5 de mayo de 2018 .
  20. ^ Varios: AspectC++ , FeatureC++, AspectC Archivado el 21 de agosto de 2006 en Wayback Machine , C orientado a AspeCt Archivado el 20 de noviembre de 2008 en Wayback Machine , Aspicere
  21. ^ "Adoquín". vub.ac.be. ​Consultado el 5 de mayo de 2018 .[ enlace muerto permanente ]
  22. ^ "Aspecto Cacao". neu.edu . Archivado desde el original el 26 de octubre de 2007 . Consultado el 5 de mayo de 2018 .
  23. ^ "Marco ColdSpring: Bienvenido". 5 de noviembre de 2005. Archivado desde el original el 5 de noviembre de 2005 . Consultado el 5 de mayo de 2018 .{{cite web}}: Mantenimiento CS1: bot: estado de la URL original desconocido ( enlace )
  24. ^ "Proyecto más cercano: AspectL". Archivado desde el original el 23 de febrero de 2011 . Consultado el 11 de agosto de 2015 .
  25. ^ "infra - Frameworks Integrados para Delphi - Alojamiento de proyectos de Google". Archivado desde el original el 9 de septiembre de 2015 . Consultado el 11 de agosto de 2015 .
  26. ^ "meaop - MeSDK: MeObjects, MeRTTI, MeAOP - Delphi AOP (programación orientada a aspectos), MeRemote, MeService... - Alojamiento de proyectos de Google". Archivado desde el original el 10 de septiembre de 2015 . Consultado el 11 de agosto de 2015 .
  27. ^ "Alojamiento de proyectos de Google". Archivado desde el original el 25 de diciembre de 2014 . Consultado el 11 de agosto de 2015 .
  28. ^ "RemObjects Cirrus". codegear.com . Archivado desde el original el 23 de enero de 2012 . Consultado el 5 de mayo de 2018 .
  29. ^ "Funciones de asesoramiento de Emacs". Proyecto GNU. Archivado desde el original el 24 de octubre de 2011 . Consultado el 5 de mayo de 2018 .
  30. ^ Las mónadas permiten alterar la semántica del programa cambiando el tipo de programa sin alterar su código: De Meuter, Wolfgang (1997). "Las mónadas como base teórica de la AOP". Taller internacional sobre programación orientada a aspectos en ECOOP : 25. CiteSeerX 10.1.1.25.8262 .  Tabareau, Nicolás; Figueroa, Ismael; Tanter, Éric (marzo de 2013). "Una incrustación monádica mecanografiada de aspectos". Actas de la duodécima conferencia internacional anual sobre desarrollo de software orientado a aspectos (PDF) . Año 2013. págs. 171–184. doi :10.1145/2451436.2451457. ISBN 9781450317665. S2CID  27256161. Las clases de tipo permiten agregar capacidades adicionales a un tipo: Sulzmann, Martin; Wang, Meng (marzo de 2007). "Programación orientada a aspectos con clases de tipos". Actas del sexto taller sobre fundamentos de lenguajes orientados a aspectos (PDF) . págs. 65–74. doi :10.1145/1233833.1233842. ISBN 978-1595936615. S2CID  3253858..
  31. ^ Muchos otros: CaesarJ Archivado el 19 de diciembre de 2008 en Wayback Machine , Compose* Archivado el 21 de agosto de 2005 en Wikiwix, Dynaop Archivado el 24 de julio de 2007 en Wayback Machine , JAC Archivado el 19 de junio de 2004 en Wayback Machine. , Google Guice (como parte de su funcionalidad), Javassist Archivado el 1 de septiembre de 2004 en Wayback Machine , JAsCo (y AWED) Archivado el 11 de abril de 2005 en Wayback Machine , JAML Archivado el 15 de abril de 2005 en Wayback Machine , JBoss AOP Archivado el 17 de octubre de 2006 en Wayback Machine , LogicAJ Archivado el 4 de mayo de 2006 en Wayback Machine , Object Teams Archivado el 31 de agosto de 2005 en Wayback Machine , PROSE Archivado el 24 de enero de 2007 en Wayback Machine , El compilador AspectBench para AspectJ (abc) Archivado el 16 de diciembre de 2014 en Wayback Machine , Spring framework (como parte de su funcionalidad), Seasar , El proyecto JMangler Archivado el 28 de octubre de 2005 en Wayback Machine , InjectJ Archivado en 2005- 05-04 en Wayback Machine , GluonJ Archivado el 6 de febrero de 2007 en Wayback Machine , Steamloom Archivado el 18 de agosto de 2007 en Wayback Machine
  32. ^ Muchos: aconsejable Archivado el 4 de julio de 2008 en Wayback Machine , Ajaxpect Archivado el 9 de julio de 2016 en Wayback Machine , complemento jQuery AOP Archivado el 13 de enero de 2008 en Wayback Machine , Aspectos Archivado el 8 de mayo de 2006 en Wikiwix , AspectJS Archivado el 16 de diciembre de 2008 en Wayback Machine , Cerny.js Archivado el 27 de junio de 2007 en Wayback Machine , Dojo Toolkit Archivado el 21 de febrero de 2006 en Wayback Machine , Humax Web Framework Archivado el 9 de diciembre de 2008 en the Wayback Machine , Joose Archivado el 18 de marzo de 2015 en Wayback Machine , Prototipo - Función de prototipo#wrap Archivado el 5 de mayo de 2009 en Wayback Machine , YUI 3 (Y.Do) Archivado el 25 de enero de 2011 en Wayback Machine
  33. ^ Uso de soporte integrado para categorías (que permite la encapsulación de código de aspecto) y programación basada en eventos (que permite la definición de controladores de eventos antes y después ).
  34. ^ "AspectLua". Archivado desde el original el 17 de julio de 2015 . Consultado el 11 de agosto de 2015 .
  35. ^ "MAKAO, sistemas de construcción de ingeniería inversa". Archivado desde el original el 24 de julio de 2012 . Consultado el 11 de agosto de 2015 .
  36. ^ "McLaboratorio". Archivado desde el original el 24 de septiembre de 2015 . Consultado el 11 de agosto de 2015 .
  37. ^ "AspectML: investigación de lenguajes de programación funcional orientados a aspectos". Archivado desde el original el 5 de diciembre de 2010 . Consultado el 11 de agosto de 2015 .
  38. ^ "nemerle/README.md en master · rsdn/nemerle". GitHub . Consultado el 22 de marzo de 2018 .
  39. ^ Adán Kennedy. "Aspecto - Programación orientada a aspectos (AOP) para Perl - metacpan.org". Archivado desde el original el 31 de agosto de 2013 . Consultado el 11 de agosto de 2015 .
  40. ^ Varios: PHP-AOP (AOP.io) Archivado el 18 de agosto de 2014 en Wikiwix, ¡Vamos! Marco AOP Archivado el 1 de marzo de 2013 en Wayback Machine , PHPaspect Archivado el 22 de agosto de 2016 en Wayback Machine , Seasar.PHP Archivado el 26 de diciembre de 2005 en Wayback Machine , PHP-AOP, Flow Archivado el 4 de enero de 2018 en Wayback Machine , Extensión AOP PECL Archivado el 11 de abril de 2017 en Wayback Machine.
  41. ^ "Programación orientada a aspectos en Prolog". bigzaphod.org . 14 de diciembre de 2005. Archivado desde el original el 3 de marzo de 2012 . Consultado el 5 de mayo de 2018 .
  42. ↑ Varios: PEAK Archivado el 9 de abril de 2005 en Wayback Machine , Aspyct AOP, AOP ligero de Python Archivado el 9 de octubre de 2004 en Wayback Machine , módulo de aspecto de Logilab Archivado el 9 de marzo de 2005 en Wayback Machine , Pythius Archivado el 2005- 08-04 en Wayback Machine , módulo AOP de Spring Python Archivado el 4 de marzo de 2016 en Wayback Machine , módulo AOP de Pytilities Archivado el 25 de agosto de 2011 en Wayback Machine , Aspectlib Archivado el 5 de noviembre de 2014 en Wayback Machine
  43. ^ "Repositorio de paquetes PLaneT: PLaneT> dutchyn> aspectoscheme.plt". Archivado desde el original el 5 de septiembre de 2015 . Consultado el 11 de agosto de 2015 .
  44. ^ "AspectR: programación sencilla orientada a aspectos en Ruby". Archivado desde el original el 12 de agosto de 2015 . Consultado el 11 de agosto de 2015 .
  45. ^ Decano Wampler. "Hogar". Archivado desde el original el 26 de octubre de 2007 . Consultado el 11 de agosto de 2015 .
  46. ^ "gcao/aspector". GitHub . Archivado desde el original el 4 de enero de 2015 . Consultado el 11 de agosto de 2015 .
  47. ^ "Aspectos". tu-ilmenau.de . Archivado desde el original el 6 de enero de 2006 . Consultado el 5 de mayo de 2018 .
  48. ^ "MetaclassTalk: reflexión y metaprogramación en Smalltalk". Archivado desde el original el 29 de julio de 2015 . Consultado el 11 de agosto de 2015 .
  49. ^ "WEAVR". iit.edu . Archivado desde el original el 12 de diciembre de 2008 . Consultado el 5 de mayo de 2018 .
  50. ^ "aspectxml: un motor de tejido XML orientado a aspectos (AXLE): alojamiento de proyectos de Google". Archivado desde el original el 12 de septiembre de 2015 . Consultado el 11 de agosto de 2015 .

Otras lecturas

enlaces externos