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 a través de una especificación de " punto de corte ", como "registrar todas las llamadas de función cuando el nombre de la función comienza con 'set ' ". Esto permite que se agreguen comportamientos que no son centrales para la lógica empresarial (como el registro) a un programa sin saturar el código de funciones centrales.

AOP incluye métodos y herramientas de programación que apoyan 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 cohesivas de funcionalidad (las llamadas preocupaciones ). Casi todos los paradigmas de programación admiten cierto 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 se pueden utilizar 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, ya que una estrategia de registro debe afectar a cada parte registrada del sistema. Por lo tanto, el registro abarca todas las clases y métodos registrados.

Todas las implementaciones de AOP tienen algunas expresiones de corte transversal que encapsulan cada preocupación en un solo lugar. La diferencia entre las implementaciones radica en la potencia, la seguridad y la facilidad de uso de las construcciones proporcionadas. Por ejemplo, los 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 de esas expresiones y las encapsula en una clase especial, llamada aspecto . Por ejemplo, un aspecto puede alterar el comportamiento del código base (la parte no relacionada con el aspecto de un programa) aplicando un consejo (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 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 optó por un enfoque de herramientas en lugar de un enfoque de diseño de lenguajes y en 2001 propuso Hyper/J y el Concern Manipulation Environment , que no se han utilizado ampliamente.

Los ejemplos de este artículo utilizan AspectJ.

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

Motivación y conceptos básicos

Normalmente, un aspecto se encuentra disperso o enredado como código, lo que dificulta su comprensión y mantenimiento. Se dispersa porque la función (como el registro) se distribuye en varias funciones no relacionadas que podrían usar su función, posiblemente en sistemas completamente no relacionados o escritos en lenguajes diferentes. Por lo tanto, cambiar el registro 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í. Por lo tanto, cambiar un aspecto implica comprender todos los aspectos enredados o tener algún medio por el cual se pueda 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: [5]

void transfer ( Cuenta desdeAcc , Cuenta aAcc , int amount ) lanza una excepción { if ( fromAcc . getBalance () < amount ) lanza una nueva InsufficientFundsException ();                 fromAcc . retirar ( monto ); toAcc . depositar ( monto ); }

Sin embargo, este método de transferencia pasa por alto ciertas consideraciones que una aplicación implementada requeriría, 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 para fines de diagnóstico.

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

void transfer ( Cuenta desdeAcc , Cuenta aAcc , int cantidad , Usuario usuario , Registrador registrador , Base de datos base de datos ) lanza una excepción { logger.info ( "Transfiriendo dinero..." ) ; si ( ! isUserAuthorised ( usuario , desdeAcc )) { logger.info ( " El usuario no tiene permiso." ) ; lanzar una nueva UnauthorisedUserException (); } si ( desdeAcc.getBalance () < cantidad ) { logger.info ( "Fondos insuficientes." ) ; lanzar una nueva InsufficientFundsException ( ) ; }                                      desdeAcc . retirar ( monto ); hastaAcc . depositar ( monto );  base de datos . commitChanges (); // Operación atómica.  logger . info ( "Transacción exitosa." ); }

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

Ahora, pensemos en 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 un cambio de este tipo 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 unido a puntos específicos en el programa) y declaraciones entre tipos (miembros estructurales añadidos a otras clases). Por ejemplo, un módulo de seguridad puede incluir consejos que realizan 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 esa manera, tanto la comprobación como los lugares se pueden mantener en un solo lugar. Además, un buen punto de corte 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 Logger { void Banco . transferencia ( Cuenta desdeAcc , Cuenta aAcc , int monto , Usuario usuario , Logger logger ) { logger . información ( "Transfiriendo dinero..." ); }                 void Banco . getMoneyBack ( Usuario usuario , int transactionId , Logger logger ) { logger . info ( "El usuario solicitó la devolución de dinero." ); }          //Otro código transversal. }

Se puede pensar en AOP como una herramienta de depuración o una herramienta a nivel de usuario. Los consejos deben reservarse para los casos en los que no se puede cambiar la función (a 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 el asesoramiento 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. Se denominan puntos de unión porque son puntos en un programa en ejecución donde se puede unir de manera útil un comportamiento adicional. Un punto de unión debe ser direccionable y comprensible para un programador común para que sea útil. También debe ser estable ante cambios intrascendentes en el programa 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. La mayoría de los lenguajes de puntos de corte más útiles utilizan una sintaxis como la del lenguaje base (por ejemplo, AspectJ utiliza 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 puntos de unión de AspectJ

Otros posibles modelos de puntos de unión

Existen otros tipos de JPM. Todos los lenguajes 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 forma de expresar preocupaciones transversales que afectan la estructura de los módulos. También conocidas como clases abiertas y métodos de extensión , permiten a los programadores declarar en un solo 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 visualización y actualización utilizando visitantes, una declaración entre tipos que utilice el patrón de visitantes podría verse así en AspectJ:

 aspecto DisplayUpdate { void Point . acceptVisitor ( Visitor v ) { v . visit ( this ); } // 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, 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 significa que la mayoría de las implementaciones producen programas de combinación compatibles a través de un tipo de transformación de programa conocida como weaving . Un weaving de aspectos lee el código orientado a aspectos y genera el código orientado a objetos apropiado con los aspectos integrados. El mismo lenguaje AOP se puede implementar a través de una variedad de métodos de weaving, por lo que la semántica de un lenguaje nunca debe entenderse en términos de la implementación del weaving. Solo 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 entrelazado a nivel de fuente utilizando preprocesadores (como se implementó C++ originalmente en CFront ) que requieren acceso a los archivos fuente del programa. Sin embargo, la forma binaria bien definida de Java permite que los entrelazadores de bytecode funcionen con cualquier programa Java en formato de archivo .class. Los entrelazadores de bytecode se pueden implementar durante el proceso de compilación o, si el modelo de entrelazado es por clase, durante la carga de la clase. AspectJ comenzó con el entrelazado a nivel de fuente en 2001, entregó un entrelazador de bytecode por clase en 2002 y ofreció soporte avanzado en 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 separen adecuadamente para mantener el modelo separado del programador. La compatibilidad de código de bytes de Java con varios archivos fuente permite que cualquier depurador pueda ejecutar un archivo .class correctamente entrelazado en un editor de código fuente. Sin embargo, algunos descompiladores de terceros no pueden procesar código entrelazado porque esperan código producido por Javac en lugar de todos los formatos de código de bytes admitidos (consulte también § Crítica, a continuación).

El entrelazado en tiempo de implementación ofrece otro enfoque. [7] Básicamente, esto implica posprocesamiento, pero en lugar de parchear el código generado, este enfoque de entrelazado 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 perfiladores, 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 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 única función específica, a menudo comparten requisitos secundarios comunes con otras clases. Por ejemplo, es posible que queramos agregar un registro a las clases dentro de la capa de acceso a datos y también a las clases en la capa de interfaz de usuario 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 principal muy diferente, el código necesario para realizar la funcionalidad secundaria a menudo es 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 deseamos aplicar siempre que el hilo ingrese o salga de un método:
Punto de corte
Esto hace referencia 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 entra en un método y se alcanza otro punto de corte cuando el hilo sale del método.
Aspecto
La combinación del punto de corte y el consejo se denomina aspecto. En el ejemplo anterior, agregamos un aspecto de registro a nuestra aplicación definiendo un punto de corte y brindando el consejo correcto.

Comparación con otros paradigmas de programación

Los aspectos surgieron 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 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. [ cita requerida ]

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 requerida ]

Aunque parezca que no tiene relación, en las pruebas, el uso de mocks o stubs requiere el uso de técnicas AOP, como around advice. Aquí, los objetos colaboradores son para el propósito de la prueba, una preocupación transversal. Por lo tanto, los diversos marcos de objetos Mock proporcionan estas características. Por ejemplo, un proceso invoca un servicio para obtener un monto de saldo. En la prueba del proceso, no es importante de dónde proviene el monto, sino solo que el proceso use el saldo de acuerdo con los requisitos. [ cita requerida ]

Problemas de adopción

Los programadores deben poder leer y comprender el código para evitar errores. [10] Incluso con la educación adecuada, comprender las cuestiones transversales puede resultar difícil sin el soporte 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 cuestiones transversales. Esas funciones, así como la asistencia y la refactorización del código de Aspect , son ahora comunes.

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

Crítica

La crítica más básica del efecto de AOP es que el flujo de control se oscurece, y que no sólo es peor que la muy difamada declaración GOTO , sino que es muy análoga a la declaración de broma COME FROM . [11] 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, en contraste con una llamada de método explícita. [11] [12] Por ejemplo, compare el programa COME FROM: [11]

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

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

main () { entrada x imprimir ( resultado ( x )) } entrada resultado ( int x ) { devolver x } alrededor ( int x ): llamar ( resultado ( int )) && args ( x ) { int temp = proceder ( x ) devolver temp * temp }

De hecho, el punto de corte puede depender de la condición de 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 el soporte de IDE que muestra qué consejos coinciden potencialmente .

Las críticas generales son que 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". [13] En concreto, la cuantificación por 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, aunque sus objetivos (modularizar las preocupaciones transversales) se entienden bien, su definición real no está 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 el ordenamiento. [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 puntos de corte se consideran intratables. Si uno reemplaza la cuantificación de los puntos de corte con anotaciones explícitas, se obtiene en cambio una programación orientada a atributos , que es simplemente una llamada explícita a una subrutina y sufre el mismo problema de dispersión, que AOP fue diseñado para resolver. [13]

Implementaciones

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

Véase también

Notas y referencias

  1. ^ 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. págs. 220–242. CiteSeerX  10.1.1.115.8660 . doi :10.1007/BFb0053381. ISBN 3-540-63089-9. Archivado (PDF) del original el 12 de enero de 2016.
  2. ^ "Programación Orientada a Objetos Adaptativa: El Enfoque 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 Box; Chris Sells (4 de noviembre de 2002). Essential.NET: El entorno de ejecución de lenguaje común . Addison-Wesley Professional. pág. 206. ISBN 978-0-201-73411-9. Recuperado el 4 de octubre de 2011 .
  4. ^ Roman, Ed; Sriganesh, Rima Patel; Brose, Gerald (1 de enero de 2005). Mastering Enterprise JavaBeans. John Wiley and Sons. pág. 285. ISBN 978-0-7645-8492-3. Recuperado 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}}: CS1 maint: copia archivada como título ( enlace )
  8. ^ B. De Win, B. Vanhaute y B. De Decker. "Seguridad mediante programación orientada a aspectos". En Advances in Network and Distributed Systems Security (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 de la 13.ª conferencia internacional sobre modularidad (desarrollo de software orientado a aspectos) de la ACM (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 Considered Harmful (PDF) . Taller interactivo europeo sobre aspectos del software (EIWAS). Berlín, Alemania. Archivado (PDF) del original el 23 de marzo de 2016 . Consultado el 5 de mayo de 2018 .
  12. ^ C2:De donde viene
  13. ^ abcde Steimann, F. (2006). "El éxito paradójico de la programación orientada a aspectos". ACM SIGPLAN Notices . 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) del original el 9 de agosto de 2017 . Consultado el 5 de mayo de 2018 .
  16. ^ Numerous: Afterthought Archivado el 15 de marzo de 2016 en Wayback Machine , LOOM.NET Archivado el 27 de agosto de 2008 en Wayback Machine , Enterprise Library 3.0 Policy Injection Application Block Archivado el 19 de enero de 2007 en Wayback Machine , AspectDNG Archivado el 29 de septiembre de 2004 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 el 25 de julio de 2006 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. ^ "Fundamento de Ada2012" (PDF) . adacore.com . Archivado (PDF) del original el 18 de abril de 2016 . Consultado el 5 de mayo de 2018 .
  19. ^ "Ganchos de función". 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 , AspectC orientado a AspectC Archivado el 20 de noviembre de 2008 en Wayback Machine , Aspicere
  21. ^ "Cobble". vub.ac.be . Consultado el 5 de mayo de 2018 .[ enlace muerto permanente ]
  22. ^ "AspectCocoa". neu.edu . Archivado desde el original el 26 de octubre de 2007 . Consultado el 5 de mayo de 2018 .
  23. ^ "ColdSpring Framework: 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}}: CS1 maint: bot: estado de URL original desconocido ( enlace )
  24. ^ "Proyecto Closer: AspectL". Archivado desde el original el 23 de febrero de 2011. Consultado el 11 de agosto de 2015 .
  25. ^ "infra – Frameworks Integrados para Delphi – Google Project Hosting". 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(Aspect Oriented Programming), MeRemote, MeService... – Google Project Hosting". Archivado desde el original el 10 de septiembre de 2015 . Consultado el 11 de agosto de 2015 .
  27. ^ "Google Project Hosting". 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 del programa sin alterar su código: De Meuter, Wolfgang (1997). "Monads As a theory basis for AOP". Taller internacional sobre programación orientada a aspectos en ECOOP : 25. CiteSeerX 10.1.1.25.8262 .  Tabareau, Nicolas; Figueroa, Ismael; Tanter, Éric (marzo de 2013). "Una incrustación monádica tipificada de aspectos". Actas de la 12.ª conferencia internacional anual sobre desarrollo de software orientado a aspectos (PDF) . Aosd '13. págs. 171–184. doi :10.1145/2451436.2451457. ISBN 9781450317665. Número de identificación del sujeto  27256161. Las clases de tipos permiten añadir 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) . pp. 65–74. doi :10.1145/1233833.1233842. ISBN 978-1595936615. Número de identificación del sujeto  3253858..
  31. ^ Numerosos 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 2005-08-31 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 el 5 de abril de 2005 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 , jQuery AOP Plugin Archivado el 13 de enero de 2008 en Wayback Machine , Aspectes 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 Wayback Machine , Joose Archivado el 18 de marzo de 2015 en Wayback Machine , Prototype – Prototype Function#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. ^ Utilizando 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, ingeniería inversa de sistemas de construcción". Archivado desde el original el 24 de julio de 2012 . Consultado el 11 de agosto de 2015 .
  36. ^ "McLab". Archivado desde el original el 24 de septiembre de 2015 . Consultado el 11 de agosto de 2015 .
  37. ^ "AspectML – Investigación sobre 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. ^ Adam Kennedy. «Aspect – Aspect-Oriented Programming (AOP) for 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, Go! AOP framework 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 , AOP PECL Extension 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, Lightweight Python AOP Archivado el 9 de octubre de 2004 en Wayback Machine , Módulo aspect de Logilab Archivado el 9 de marzo de 2005 en Wayback Machine , Pythius Archivado el 8 de abril de 2005 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 de PLaneT: PLaneT > dutchyn > aspectscheme.plt". Archivado desde el original el 5 de septiembre de 2015 . Consultado el 11 de agosto de 2015 .
  44. ^ "AspectR – Programación orientada a aspectos simple en Ruby". Archivado desde el original el 12 de agosto de 2015 . Consultado el 11 de agosto de 2015 .
  45. ^ Dean Wampler. «Home». 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 interconexión 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 .

Lectura adicional

Enlaces externos