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 un comportamiento adicional al código existente (un consejo ) sin modificar el código en sí, en lugar de especificar por separado qué código se modifica a través de una especificación " pointcut ", como "registrar todas las llamadas a funciones cuando el nombre de la función comienza con 'set ' ". Esto permite comportamientos que no son fundamentales para la lógica empresarial. (como el registro) para agregarlo a un programa sin saturar el núcleo del código de la funcionalidad.
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 distintas partes (las llamadas preocupaciones , áreas cohesivas de funcionalidad). 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 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 porque una estrategia de registro afecta necesariamente a todas las partes registradas del sistema. De este modo, el registro cruza 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 las 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 de estas expresiones y las encapsula en una clase especial, un aspecto . Por ejemplo, un aspecto puede alterar el comportamiento del código base (la parte que no es de aspecto de un programa) aplicando consejos (comportamiento adicional) en varios puntos de unión (puntos en un programa) especificados en una cuantificación o consulta llamada pointcut ( 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 al sujeto , 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 herramientas sobre un enfoque de diseño de lenguaje y en 2001 propuso Hyper / J y el Entorno de manipulación de inquietudes , 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
Por lo general, un aspecto está disperso o enredado como código, lo que dificulta su comprensión y mantenimiento. Se dispersa en virtud de que la función (como el registro) se distribuye en una serie de funciones no relacionadas que podrían usar su función, posiblemente en sistemas completamente no relacionados, diferentes lenguajes fuente, etc. Eso significa que 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í. Eso significa que 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]
transferencia nula ( Cuenta fromAcc , Cuenta toAcc , cantidad int ) arroja Excepción { if ( fromAcc . getBalance () < cantidad ) throw new InsufficientFundsException (); fromAcc . retirar ( cantidad ); toAcc . depósito ( cantidad ); }
Sin embargo, este método de transferencia pasa por alto ciertas consideraciones que requeriría una aplicación implementada: carece de controles de seguridad para verificar que el usuario actual tiene la autorización para realizar esta operación; una transacción de base de datos debe encapsular la operación para evitar la pérdida accidental de datos; para el diagnóstico, la operación debe registrarse en el registro del sistema, etc.
Una versión con todas esas nuevas preocupaciones, por el bien de ejemplo, podría verse algo así:
Transferencia nula ( Cuenta fromAcc , Cuenta toAcc , cantidad int , Usuario usuario , Logger logger , Base de datos de la base de datos ) arroja Exception { logger . info ( "Transfiriendo dinero ..." ); if ( ! isUserAuthorised ( usuario , fromAcc )) { registrador . info ( "El usuario no tiene permiso" ); lanzar nueva UnauthorisedUserException (); } if ( fromAcc . getBalance () < cantidad ) { logger . info ( "Fondos insuficientes" ); lanzar nueva InsufficientFundsException (); } fromAcc . retirar ( cantidad ); toAcc . depósito ( cantidad ); base de datos . commitChanges (); // 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 de lógica empresarial ). Las transacciones, la seguridad y el registro son ejemplos de preocupaciones transversales .
Ahora considere lo que sucede si de repente necesitamos cambiar (por ejemplo) las consideraciones de seguridad para 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 unido a puntos especificados en el programa) y declaraciones entre tipos (miembros estructurales agregados a otras clases). Por ejemplo, un módulo de seguridad puede incluir un aviso que realiza un control de seguridad antes de acceder a una cuenta bancaria. El punto de acceso define los tiempos ( puntos de unión ) en los que se puede acceder a una cuenta bancaria, y el código en el cuerpo de asesoramiento define cómo se implementa el control de seguridad. De esa manera, tanto el cheque como los lugares se pueden mantener en un solo lugar. Además, un buen pointcut puede anticipar cambios de programa posteriores, 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 implementando el registro en un aspecto:
Aspecto Logger { void Bank . transferencia ( Cuenta fromAcc , Cuenta toAcc , cantidad int , Usuario usuario , Logger logger ) { logger . info ( "Transfiriendo dinero ..." ); } banco vacío . getMoneyBack ( Usuario usuario , int transactionId , Logger logger ) { logger . 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 como una herramienta a nivel de usuario. Los consejos deben reservarse para los casos en los que no pueda cambiar la función (nivel de usuario) [6] o no desee cambiar la función en el código de producción (depuración).
Modelos de puntos de unió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:
- Cuando el consejo puede correr. Estos se denominan puntos de unión porque son puntos en un programa en ejecución donde se pueden unir comportamientos adicionales de manera útil. Un punto de unión debe ser direccionable y comprensible por un programador común para que sea útil. También debe ser estable a través de cambios de programa intrascendentes para que un aspecto sea estable a través de dichos cambios. Muchas implementaciones de AOP admiten ejecuciones de métodos y referencias de campo como puntos de unión.
- Una forma de especificar (o cuantificar ) puntos de unión, llamados cortes de puntos . Los puntos de acceso determinan si un punto de unión determinado coincide. La mayoría de los lenguajes de corte de puntos utilizan una sintaxis como el lenguaje base (por ejemplo, AspectJ usa firmas Java) y permiten la reutilización a través de nombres y combinaciones.
- 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 cosas como definir 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
- Los puntos de unión en AspectJ incluyen la llamada o ejecución de método o constructor, la inicialización de una clase u objeto, acceso de lectura y escritura de campo, manejadores de excepciones, etc. No incluyen bucles, super llamadas, cláusulas throws, declaraciones múltiples, etc.
- Los cortes de puntos se especifican mediante combinaciones de designadores de cortes de puntos primitivos (PCD).
Los PCD "Kinded" coinciden con un tipo particular de punto de unión (por ejemplo, ejecución de método) y tienden a tomar como entrada una firma similar a Java. Uno de esos cortes de puntos se ve así:
ejecución (* set * (*))
Este punto de corte coincide con un punto de unión de ejecución de método, si el nombre del método comienza con "
set
" y hay exactamente un argumento de cualquier tipo.Los PCD "dinámicos" comprueban los tipos de ejecución y vinculan variables. Por ejemplo,
este punto)
Este pointcut coincide cuando el objeto que se está ejecutando actualmente es una instancia de class
Point
. Tenga en cuenta que el nombre no calificado de una clase se puede utilizar mediante la búsqueda de tipo normal de Java.Los PCD de "alcance" limitan el alcance léxico del punto de unión. Por ejemplo:
dentro de (com.company. *)
Este punto de corte coincide con cualquier punto de unión en cualquier tipo del
com.company
paquete. El*
es una de las formas de los comodines que se pueden utilizar para que coincida con muchas cosas con una firma.Los cortes de puntos se pueden componer y nombrar para su reutilización. Por ejemplo:
Este punto de corte coincide con un punto de unión de ejecución de método, si el nombre del método comienza con "pointcut set () : ejecución ( * set * ( * ) ) && this ( Point ) && dentro de ( com . company . * );
set
" ythis
es una instancia de tipoPoint
en elcom.company
paquete. Se puede hacer referencia a él mediante el nombre "set()
". - El consejo especifica que se ejecute en (antes, después o alrededor) de un punto de unión (especificado con un punto de corte) cierto código (especificado como código en un método). El tiempo de ejecución de AOP invoca a Advice automáticamente cuando el punto de corte coincide con el punto de unión. Por ejemplo: after (): set () {Display.update (); } Esto especifica efectivamente: "si el punto de
set()
corte coincide con el punto de unión, ejecute el códigoDisplay.update()
después de que se complete el punto de unión".
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:
- Los puntos de unión son todos elementos del modelo.
- Los cortes de puntos son expresiones booleanas que combinan los elementos del modelo.
- Los medios de efecto en estos puntos son una visualización de todos los puntos de unión emparejados.
Declaraciones entre tipos
Las declaraciones entre tipos proporcionan una forma 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, normalmente para combinar todo el código relacionado con una preocupación en un aspecto. Por ejemplo, si un programador implementó la preocupación de actualización de visualización transversal usando visitantes en su lugar, una declaración entre tipos usando el patrón de visitante podría verse así en AspectJ:
aspecto DisplayUpdate { punto vacío . acceptVisitor ( Visitante v ) { v . visitar ( esto ); } // otro código de corte transversal ... }
Este fragmento de código agrega el acceptVisitor
método a la Point
clase.
Es un requisito 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 formas diferentes, según los lenguajes y entornos subyacentes:
- Se produce un programa combinado, válido en el idioma original e indistinguible de un programa ordinario al intérprete definitivo.
- el intérprete o el entorno definitivo se actualiza para comprender e implementar las funciones de AOP.
La dificultad de cambiar los entornos 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 conocido como tejido . Un tejedor de aspectos lee el código orientado a aspectos y genera código apropiado orientado a objetos con los aspectos integrados. El mismo lenguaje AOP se puede implementar a través de 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. Solo la velocidad de una implementación y su facilidad de implementación se ven afectadas por el método de combinación que se utilice.
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 forma de archivo .class. Los tejedores de códigos 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 correctamente para mantener el modelo segregado del programador. El soporte de código de bytes de Java para múltiples archivos de origen permite a cualquier depurador recorrer un archivo .class correctamente tejido en un editor de origen. 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 bytecode admitidas (ver también § Crítica , más abajo).
El tejido en tiempo de implementación ofrece otro enfoque. [7] Esto básicamente implica posprocesamiento, pero en lugar de parchear el código generado, este enfoque de tejido subclasifica las clases existentes para que las modificaciones se introduzcan mediante la invalidación del método. Las clases existentes permanecen intactas, incluso en tiempo de ejecución, y todas las herramientas existentes (depuradores, perfiladores, etc.) se pueden utilizar durante el desarrollo. Un enfoque similar ya ha demostrado su eficacia en la aplicación de muchas de Java EE servidores de aplicaciones, tales como IBM 's WebSphere .
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 OO realizarán una única función específica, a menudo comparten requisitos secundarios comunes con otras clases. Por ejemplo, es posible que deseemos agregar el registro a las clases dentro de la capa de acceso a datos y también a las clases en la capa de la interfaz de usuario cada vez que un hilo entra 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 es a menudo 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.
- Pointcut
- Este es el término que se le da al punto de ejecución en la aplicación en el que se debe aplicar la preocupación transversal. En nuestro ejemplo, se alcanza un punto cuando el hilo entra en un método, y se alcanza otro punto 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 dando los consejos correctos.
Comparación con otros paradigmas de programación
Los aspectos surgieron de la programación orientada a objetos y la reflexión computacional . Los lenguajes AOP tienen una funcionalidad similar, pero más restringida, que los protocolos de metaobjetos . Los aspectos se relacionan estrechamente con conceptos de programación como materias , mixins y delegación . Otras formas de utilizar paradigmas de programación orientados a aspectos incluyen filtros de composición y el enfoque de hiperslices . Desde al menos la década de 1970, los desarrolladores han estado usando formas de interceptación y despacho de parches 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 escrita en un solo lugar. [ cita requerida ]
Los diseñadores han considerado formas alternativas de lograr la separación de código, como los tipos parciales de C # , pero tales 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 no tener relación, en las pruebas, el uso de simulacros o resguardos requiere el uso de técnicas de AOP, como consejos, etc. Aquí los objetos colaboradores son para el propósito de la prueba, una preocupación transversal. Por lo tanto, los distintos marcos de Mock Object proporcionan estas características. Por ejemplo, un proceso invoca un servicio para obtener un saldo. En la prueba del proceso, de donde viene la cantidad no es importante, solo que el proceso usa el saldo de acuerdo a los requerimientos. [ cita requerida ]
Problemas de adopción
Los programadores deben poder leer el código y comprender lo que está sucediendo para evitar errores. [10] Incluso con la 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 preocupaciones transversales. Esas características, así como la asistencia de código de aspecto y la refactorización ahora son comunes.
Dado el poder de AOP, si un programador comete un error lógico al expresar los cortes transversales, puede provocar una falla generalizada del programa. A la inversa, otro programador puede cambiar los puntos de unión en un programa, por ejemplo, cambiando el nombre o moviendo métodos, de formas que el escritor de aspecto no anticipó, 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 presentan como un conflicto de responsabilidad entre dos o más desarrolladores por una falla determinada. Sin embargo, la solución para estos problemas puede ser mucho más fácil en presencia de AOP, ya que solo es necesario cambiar el aspecto, mientras que los problemas correspondientes sin AOP 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 está oscurecido, y que no solo es peor que el tan difamado GOTO , sino que de hecho es muy análogo a la declaración de 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 se especifica en cambio en el punto de corte), significa que el consejo no es visible, por el contrario a una llamada de método explícito. [11] [12] Por ejemplo, compare el programa COME FROM: [11]
5 INPUT X 10 PRINT 'El resultado es:' 15 PRINT X 20 VEN DE 10 25 X = X * X 30 REGRESO
con un fragmento AOP con semántica análoga:
main () { input x print ( result ( x )) } input result ( int x ) { return x } around ( int x ): call ( result ( int )) && args ( x ) { int temp = continue ( x ) temperatura de retorno * temp}
De hecho, el corte de puntos puede depender de la condición de tiempo de ejecución y, por lo tanto, no ser estadísticamente determinista. Esto se puede mitigar, pero no resolver, mediante análisis estático y soporte IDE que muestre qué consejos coinciden potencialmente .
Las críticas generales son que AOP pretende mejorar "tanto la modularidad como la estructura del código", pero algunos contrarrestan que, en cambio, socava estos objetivos e impide "el desarrollo independiente y la comprensibilidad de los programas". [13] Específicamente, la cuantificación por cortes de puntos 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 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 realización de pedidos. [13] De hecho, los aspectos pueden aplicarse a sí mismos, dando lugar a problemas como la paradoja del mentiroso . [15]
Las críticas técnicas incluyen que la cuantificación de los pointcuts (que define dónde se ejecutan los consejos) es "extremadamente sensible a los cambios en el programa", lo que se conoce como el problema del pointcut frágil . [13] Los problemas con los pointcuts se consideran intratables: si uno reemplaza la cuantificación de pointcuts con anotaciones explícitas, en su lugar se obtiene una programación orientada a atributos , que es simplemente una llamada de subrutina explícita y sufre el mismo problema de dispersión que AOP fue diseñado para resolver. . [13]
Implementaciones
Los siguientes lenguajes de programación han implementado AOP, dentro del lenguaje o como una biblioteca externa:
- Lenguajes de .NET Framework ( C # / VB.NET ) [16]
- PostSharp es una implementación de AOP comercial con una edición gratuita pero limitada.
- Unity proporciona una API para facilitar prácticas comprobadas en áreas centrales de programación, incluido el acceso a datos, seguridad, registro, manejo de excepciones y otros.
- ActionScript [17]
- Ada [18]
- AutoHotkey [19]
- C / C ++ [20]
- COBOL [21]
- Los marcos de Cocoa Objective-C [22]
- ColdFusion [23]
- Lisp común [24]
- Delfos [25] [26] [27]
- Prisma de Delphi [28]
- e (IEEE 1647)
- Emacs Lisp [29]
- Groovy
- Haskell [30]
- Java [31]
- AspectoJ
- JavaScript [32]
- Logtalk [33]
- Lua [34]
- hacer [35]
- Matlab [36]
- ML [37]
- Perl [38]
- PHP [39]
- Prólogo [40]
- Python [41]
- Raqueta [42]
- Rubí [43] [44] [45]
- Squeak Smalltalk [46] [47]
- UML 2.0 [48]
- XML [49]
Ver también
- AOP distribuido
- Gramática de atributos , un formalismo que se puede utilizar para la programación orientada a aspectos además de los lenguajes de programación funcionales.
- Paradigmas de programación
- Programación orientada a temas , 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 de decorador
- Diseño impulsado por dominios
notas y referencias
- ^ 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 XI Conferencia Europea de Programación Orientada a Objetos . LNCS . 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.
- ^ "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 reconoció posteriormente esto y reformuló su enfoque).
- ^ Don Box; Chris Sells (4 de noviembre de 2002). Essential.NET: Common Language Runtime . Addison-Wesley Professional. pag. 206 . ISBN 978-0-201-73411-9. Consultado el 4 de octubre de 2011 .
- ^ Roman, 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 .
- ^ Nota: Los ejemplos de este artículo aparecen en una sintaxis similar a la dellenguaje Java .
- ^ "gnu.org" . www.gnu.org . Archivado desde el original el 24 de diciembre de 2017 . Consultado el 5 de mayo de 2018 .
- ^ "Copia archivada" (PDF) . Archivado desde el original (PDF) el 8 de octubre de 2005 . Consultado el 19 de junio de 2005 .CS1 maint: copia archivada como título ( enlace )
- ^ B. De Win, B. Vanhaute y B. De Decker. "Seguridad mediante programación orientada a aspectos". En Avances en Seguridad de Redes y Sistemas Distribuidos (2002).
- ^ T. Pasquier, J. Bacon y B. Shand. "FlowR: Programación orientada a aspectos para el control del flujo de información en Ruby". En ACM Proceedings of the 13th international conference on Modularity (Aspect Oriented Software Development) (2014).
- ↑ Edsger Dijkstra , Notes on Structured Programming Archivado el 12 de octubre de 2006 en Wayback Machine , pág. 1-2
- ^ a b c d 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 .
- ^ C2: Venir de
- ^ a b c d e 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 Archivado 2016-03-04 en Wayback Machine , diapositivas 2 Archivado 2015-09-23 en Wayback Machine , resumen Archivado 2015-09-24 en Wayback Machine ), Friedrich Steimann, Gary T. Leavens, OOPSLA 2006
- ^ "Razonamiento más modular para programas orientados a aspectos" . Archivado desde el original el 12 de agosto de 2015 . Consultado el 11 de agosto de 2015 .
- ^ "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 .
- ^ Numerous: Afterthought Archivado 2016-03-15 en Wayback Machine , LOOM.NET Archivado 2008-08-27 en Wayback Machine , Enterprise Library 3.0 Policy Injection Application Block Archivado 2007-01-19 en Wayback Machine , AspectDNG Archivado 2004 -09-29 en Wayback Machine , DynamicProxy Archivado 2015-12-05 en Wayback Machine , Compose * Archivado 2005-08-21 en Wikiwix, PostSharp Archivado 2016-05-03 en Wayback Machine , Seasar.NET Archivado 2006- 07-25 en Wayback Machine , DotSpect (.SPECT) Archivado 2006-03-31 en Wayback Machine , Spring.NET Archivado 2006-04-02 en Wayback Machine (como parte de su funcionalidad), Wicca y Phx.Morph Archivado 2006-12-07 en Wayback Machine , SetPoint Archivado 2008-10-07 en Wayback Machine
- ^ "Bienvenido a as3-commons-bytecode" . as3commons.org . Archivado desde el original el 3 de octubre de 2014 . Consultado el 5 de mayo de 2018 .
- ^ "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 .
- ^ "Función Ganchos" . autohotkey.com . Archivado desde el original el 17 de enero de 2013 . Consultado el 5 de mayo de 2018 .
- ^ Varios: AspectC ++ , FeatureC ++ , AspectC Archivado 2006-08-21 en Wayback Machine , C orientado a AspeCt Archivado 2008-11-20 en Wayback Machine , Aspicere
- ^ "Adoquín" . vub.ac.be . Consultado el 5 de mayo de 2018 .[ enlace muerto permanente ]
- ^ "AspectCocoa" . neu.edu . Archivado desde el original el 26 de octubre de 2007 . Consultado el 5 de mayo de 2018 .
- ^ "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 .CS1 maint: bot: estado de URL original desconocido ( enlace )
- ^ "Proyecto más cercano: AspectL" . Archivado desde el original el 23 de febrero de 2011 . Consultado el 11 de agosto de 2015 .
- ^ "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 .
- ^ "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 .
- ^ "Alojamiento de proyectos de Google" . Archivado desde el original el 25 de diciembre de 2014 . Consultado el 11 de agosto de 2015 .
- ^ "RemObjects Cirrus" . codegear.com . Archivado desde el original el 23 de enero de 2012 . Consultado el 5 de mayo de 2018 .
- ^ "Funciones de asesoramiento de Emacs" . gnu.org . Archivado desde el original el 24 de octubre de 2011 . Consultado el 5 de mayo de 2018 .
- ^ Las mónadas permiten modificar la semántica del programa cambiando el tipo de programa sin alterar su código: De Meuter, Wolfgang (1997). "Mónadas como base teórica para AOP". Taller Internacional de Programación Orientada a Aspectos en ECOOP . 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 . Aosd '13: 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 los fundamentos de los lenguajes orientados a aspectos : 65–74. doi : 10.1145 / 1233833.1233842 . ISBN 978-1595936615. S2CID 3253858 ..
- ^ Muchos otros: CaesarJ Archivado 2008-12-19 en Wayback Machine , Compose * Archivado 2005-08-21 en Wikiwix, Dynaop Archivado 2007-07-24 en Wayback Machine , JAC Archivado 2004-06-19 en Wayback Machine , Google Guice (como parte de su funcionalidad), Javassist Archivado 2004-09-01 en Wayback Machine , JAsCo (y AWED) Archivado 2005-04-11 en Wayback Machine , JAML Archivado 2005-04-15 en Wayback Machine , JBoss AOP Archivado el 17 de octubre de 2006 en la Wayback Machine , LogicAJ Archivado el 4 de mayo de 2006 en la Wayback Machine , Object Teams Archivado el 31 de agosto de 2005 en la Wayback Machine , PROSE Archivado el 24 de enero de 2007 en la Wayback Machine , The AspectBench Compiler for AspectJ (abc) Archivado 2014-12-16 en Wayback Machine , Spring framework (como parte de su funcionalidad), Seasar , The JMangler Project Archivado 2005-10-28 en Wayback Machine , InjectJ Archivado 2005- 04-05 en Wayback Machine , GluonJ Archivado 2007-02-06 en Wayback Machine , Steamloom Archivado 2007-08-18 en Way máquina trasera
- ^ Many: Advisable Archivado 2008-07-04 en Wayback Machine , Ajaxpect Archivado 2016-07-09 en Wayback Machine , jQuery AOP Plugin Archivado 2008-01-13 en Wayback Machine , Aspectes Archivado 2006-05-08 en Wikiwix , AspectJS Archivado 2008-12-16 en Wayback Machine , Cerny.js Archivado 2007-06-27 en Wayback Machine , Dojo Toolkit Archivado 2006-02-21 en Wayback Machine , Humax Web Framework Archivado 2008-12-09 en la Wayback Machine , Joose archivado 03/18/2015 en la Wayback Machine , Prototipo - prototipo de la función # envoltura archivado 2009-05-05 en la Wayback Machine , YUI 3 (Y.Do) archivado 2011-01-25 en la Wayback Machine
- ^ Uso de soporte integrado para categorías (que permite la encapsulación del código de aspecto) y programación dirigida por eventos (que permite la definición decontroladores de eventos antes y después).
- ^ "AspectLua" . Archivado desde el original el 17 de julio de 2015 . Consultado el 11 de agosto de 2015 .
- ^ "MAKAO, re (verso) -ingeniería construir sistemas" . Archivado desde el original el 24 de julio de 2012 . Consultado el 11 de agosto de 2015 .
- ^ "McLab" . Archivado desde el original el 24 de septiembre de 2015 . Consultado el 11 de agosto de 2015 .
- ^ "AspectML - Investigación en lenguaje de programación funcional orientado a aspectos" . Archivado desde el original el 5 de diciembre de 2010 . Consultado el 11 de agosto de 2015 .
- ^ Adam Kennedy. "Aspectos - 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 .
- ^ Varios: PHP-AOP (AOP.io) Archivado el 18 de agosto de 2014 en Wikiwix, Go! Marco AOP Archivado 2013-03-01 en Wayback Machine , PHPaspect Archivado 2016-08-22 en Wayback Machine , Seasar.PHP Archivado 2005-12-26 en Wayback Machine , PHP-AOP , Flow Archivado 2018-01-04 en Wayback Machine , Extensión AOP PECL Archivado el 11 de abril de 2017 en Wayback Machine
- ^ "bigzaphod.org llegará pronto" . www.bigzaphod.org . Archivado desde el original el 20 de abril de 2016 . Consultado el 5 de mayo de 2018 .
- ^ Varios: PEAK Archivado 2005-04-09 en Wayback Machine , Aspyct AOP , Lightweight Python AOP Archivado 2004-10-09 en Wayback Machine , módulo de aspecto de Logilab Archivado 2005-03-09 en Wayback Machine , Pythius Archivado 2005- 04-08 en Wayback Machine , módulo AOP de Spring Python Archivado 2016-03-04 en Wayback Machine , módulo AOP de Pytilities Archivado 2011-08-25 en Wayback Machine , aspectlib Archivado 2014-11-05 en Wayback Machine
- ^ "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 .
- ^ "AspectR - Programación simple orientada a aspectos en Ruby" . Archivado desde el original el 12 de agosto de 2015 . Consultado el 11 de agosto de 2015 .
- ^ Dean Wampler. "Inicio" . Archivado desde el original el 26 de octubre de 2007 . Consultado el 11 de agosto de 2015 .
- ^ "gcao / aspector" . GitHub . Archivado desde el original el 4 de enero de 2015 . Consultado el 11 de agosto de 2015 .
- ^ "ASPECTOS" . tu-ilmenau.de . Archivado desde el original el 6 de enero de 2006 . Consultado el 5 de mayo de 2018 .
- ^ "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 .
- ^ "WEAVR" . iit.edu . Archivado desde el original el 12 de diciembre de 2008 . Consultado el 5 de mayo de 2018 .
- ^ "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
- 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 XI Conferencia Europea de Programación Orientada a Objetos . LNCS . 1241 . págs. 220–242. CiteSeerX 10.1.1.115.8660 . doi : 10.1007 / BFb0053381 . ISBN 3-540-63089-9. El documento generalmente se considera la referencia autorizada para AOP.
- Andreas Holzinger; M. Brugger; W. Slany (2011). Aplicación de programación orientada a aspectos (AOP) en procesos de ingeniería de usabilidad: en el ejemplo de seguimiento de información de uso para pruebas de usabilidad remotas . Actas de la 8ª Conferencia Internacional sobre Comercio Electrónico y Telecomunicaciones. Sevilla . DA Marca, B. Shishkov y M. v. Sinderen (editores). págs. 53–56.
- Robert E. Filman; Tzilla Elrad; Siobhán Clarke; Mehmet Aksit (2004). Desarrollo de software orientado a aspectos . ISBN 978-0-321-21976-3.
- Renaud Pawlak, Lionel Seinturier y Jean-Philippe Retaillé (2005). Fundamentos de AOP para el desarrollo J2EE . ISBN 978-1-59059-507-7.
- Laddad, Ramnivas (2003). AspectJ en acción: programación práctica orientada a aspectos . ISBN 978-1-930110-93-9.
- Jacobson, Ivar ; Pan-Wei Ng (2005). Desarrollo de software orientado a aspectos con casos de uso . 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 . ISBN 978-0-321-24674-5.
- Raghu Yedduladoddi (2009). Desarrollo de software orientado a aspectos: un enfoque para componer modelos de diseño UML . ISBN 978-3-639-12084-4.
- "Programación adaptativa orientada a objetos mediante personalización basada en gráficos" - Lieberherr, Silva-Lepe, et al. - 1994
- Zambrano Polo y La Borda, Arturo Federico (5 de junio de 2013). "Abordar las interacciones de los aspectos en un entorno industrial: experiencias, problemas y soluciones" : 159 . Consultado el 30 de mayo de 2014 . Cite journal requiere
|journal=
( ayuda ) - Wijesuriya, Viraj Brian (2016-08-30) Desarrollo orientado a aspectos, notas de la conferencia, Facultad de Computación de la Universidad de Colombo, Sri Lanka
- Groves, Matthew D. (2013). AOP en .NET . ISBN 9781617291142.
enlaces externos
- Lista de herramientas AOP de Eric Bodden en el marco .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" . JavaWorld . Consultado el 20 de julio de 2020 . Una serie detallada de artículos sobre los conceptos básicos 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 restricción
- Programación orientada a objetos frente a aspectos: ¿qué técnica y cuándo?
- Gregor Kiczales, profesor de Ciencias de la Computación, explicando AOP , video 57 min.
- Programación orientada a aspectos en COBOL Archivado el 17 de diciembre de 2008 en la Wayback Machine.
- Programación orientada a aspectos en Java con Spring Framework
- Wiki dedicado 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 Bilkent University
- Introducción a AOP - Podcast de radio de ingeniería de software Episodio 106
- Una implementación de Objective-C de AOP por Szilveszter Molnar
- Programación orientada a aspectos para iOS y OS X por Manuel Gebele
- DevExpress MVVM Framework. Introducción a los ViewModels de POCO