Historia


Desde el año de 1970 se empezaron a adoptar una serie de términos y metodologías que repercutieron en el surgimiento de la programación orientada a aspectos. En primer lugar Edsger W. Dijkstra introdujo la llamada "Separation of Concerns" - separación de incumbencias en español - con lo cual se aborda el enfoque de distinción de las funcionalidades básicas de las de uso común en un sistema.

Posteriormente, desde la década de los 80 hasta la década de los 90, se implementaron tecnologías que permitían el rediseño del software en tiempo dinámico, a saber: el protocolo de metaobjetos con la aplicación SmallTalk-80; la Reflexión en lenguajes procedurales y los filtros de composición.

La historia de la programación orientada a aspectos toma impulso en el año 1991 con el grupo Demeter quienes trabajaban investigando acerca de lo que podríamos denominar una etapa temprana de POA, la programación adaptativa, la cual, basada en basada en el uso de autómatas finitos y una teoría formal de lenguaje para expresar concisamente y procesar eficientemente conjuntos de caminos en un grafo arquitectónico, representó un gran avance dentro de la tecnología de software.

Este mismo grupo Demeter en el año de 1987 propuso la llamada "Ley Demeter", una regla aplicada en el diseño de software en sistemas basados en objetos: "Sólo conversa con tus amigos inmediatos", ésta ley inspiró en el desarrollo de la programación adaptativa y eventualmente la programación orientada a aspectos dado que para escribir código respetando ésta ley habían secciones del código que debían ser claramente encapsuladas para dejar la funcionalidad básica libre de cualquier concepto relacionado con el comportamiento del software.

Es importante resaltar tambien las contribuciones de Karl Lieberherr , quien es un científico de la computación. A mediados de los 1980s empieza una investigación sobre la Programación Orientada a Objetos, enfocado en los problemas del diseño de software y la modularidad. A partir de esto empieza un desarrollo de la idea de Programación Orientada a Aspectos. Se atribuye la creción del grupo Demeter, que como ya sabemos fue importante en el desarrollo del concepto de POA. Además también diseña la Ley de Demeter y crea varios sistemas que ayudan a pasar de una Programación Orientada a Objetos, a una Programación Orientada a Aspectos como lo son Demeter/C++, DemeterJ, Demeter/Flavors, entre otros.

No fue sino hasta 1995 cuando Cristina Lopes junto con Walter Huersch realizaron un reporte acerca de la separación de los conceptos de comportamiento de los conceptos de funcionalidad, incluso mencionaron técnicas iniciales para poder realizar dicha separación: filtros composicionales y programación adaptativa para tratar con los conceptos entrecruzados.

En éste reporte se dejó claro como la separación de conceptos era uno de los retos más importantes en el progreso de la ingeniería de software.

En éste mismo año el grupo "Demeter" dio lo que sería la primera definición de Aspecto: "Un aspecto es una unidad que se define en términos de información parcial de otras unidades.", en éste grupo se encontraba Gregor Kickzales quien dentro de la literatura se considera como el creador de la programación orientada a aspectos.


En los años 80s la necesidad de los equipos de programadores para modularizar su trabajo aumentó, esto debido a que anteriormente ciertos programas eran como "cajas negras", cuyo contenido era muy complejo de interpretar por lo que el trabajo en equipo se hacía muy tedioso. A medida que la necesidad de personalizar la funcionalidad de los módulos aumentaba, se introdujo la herencia, permitiendo a los programadores extender o limitar la funcionalidad de un módulo sin redefinirlo. Estas ideas evolucionaron y se combinaron en nuestra concepción moderna de la Orientación a Objetos (OO). Sin embargo aún seguía la dificultad para reutilizar y lograr que el código fuera mantenible.

Fue en los años 90 en los que Gregor Kiczales y su equipo en Xerox PARC empezaron a abordar esta problemática, desarrollando la Programación Orientada a Aspectos (AOP), con esta buscaban una mejor forma de modularizar el código y hacerse cargo de distintas preocupaciones transversales, entres ellas la seguridad y la trazabilidad, todo esto de manera aislada para asegurar su fácil mantenimiento.

En la actualidad AspecJ, creado en 2001, ha recibido una gran acogida por la comunidad del desarrollo de software, en especial en frameworks de Java como lo son Spring o Spring Boot.

La consolidación industrial de AOP (2003–2013)

En 2003, Xerox PARC donó el proyecto AspectJ a la Fundación Eclipse, que asumió su mantenimiento bajo el nombre Eclipse AspectJ. Este cambio fue determinante: AOP dejó de ser exclusivamente un proyecto de investigación académica y ganó soporte industrial y ciclos de versiones gestionados. Ese mismo año, el recién nacido Spring Framework integró soporte AOP como uno de sus pilares fundamentales, exponiéndolo a la industria empresarial Java por primera vez a gran escala.

Durante los años siguientes, la adopción de AOP enfrentó una barrera práctica: configurarlo requería archivos XML extensos. La adopción de anotaciones (AspectJ 5, 2005) y su integración con Spring simplificó drásticamente la configuración basada en XML, permitiendo definir aspectos directamente en Java mediante anotaciones como @Aspect, @Before y @Around. Ese mismo año, Java EE 5 estandarizó los interceptores en la especificación EJB 3.0, y más tarde CDI 1.0 en 2009 los consolidó como parte central de la plataforma. Aunque el vocabulario era distinto, el modelo conceptual era el mismo que el de AOP: interceptar puntos de ejecución para insertar comportamiento transversal sin modificar el código base.

Para 2011, anotaciones como @Cacheable, @Async y @PreAuthorize eran de uso cotidiano en millones de líneas de código en producción, todas implementadas internamente como aspectos de Spring. La mayoría de los desarrolladores que las usaban no las identificaban como AOP.

Spring Boot y la invisibilización de AOP (2014–2018)

El lanzamiento de Spring Boot 1.0 en abril de 2014 profundizó esta tendencia. Al automatizar la configuración del framework, Spring Boot hizo que los aspectos se activaran solos según las dependencias presentes en el proyecto. Esto democratizó el paradigma de forma masiva, aunque al costo de que sus mecanismos internos se volvieran cada vez más opacos para quienes lo usaban a diario.

GraalVM y el retorno al weaving en compilación (2018–2024)

El desafío más significativo de los años siguientes llegó con GraalVM Native Image, anunciado por Oracle en 2018, que permite compilar aplicaciones Java a binarios nativos con tiempos de arranque de milisegundos. El problema es que esta compilación es incompatible con el runtime weaving tradicional de AOP: la generación dinámica de proxies y la reflexión sin declaración explícita son técnicas que GraalVM no puede procesar estáticamente. Dos frameworks respondieron apostando por trasladar el weaving al tiempo de compilación: Micronaut en 2018 y Quarkus en 2019. Ambos resuelven sus aspectos durante el build mediante procesadores de anotaciones de Java, minimizando o evitando la necesidad de reflexión y proxies dinámicos en ejecución para las capacidades transversales principales, y logrando plena compatibilidad con GraalVM sin sacrificar las capacidades transversales del paradigma.

Spring siguió un camino propio. Con el lanzamiento de Spring Framework 6.0 y Spring Boot 3.0 en noviembre de 2022, el framework introdujo un sistema de procesamiento en tiempo de compilación llamado AOT (Ahead-Of-Time), que analiza los aspectos durante el build y genera las configuraciones necesarias para que funcionen correctamente en imágenes nativas. Por primera vez, aplicaciones Spring con gestión transaccional y seguridad basadas en aspectos podían compilarse a binarios nativos de forma oficial.

En paralelo, la proliferación de arquitecturas de microservicios trajo consigo una nueva categoría de incumbencias transversales: la observabilidad distribuida. OpenTelemetry, estándar abierto formado en 2019, instrumenta automáticamente aplicaciones Java mediante un agente que aplica load-time weaving usando la biblioteca Byte Buddy. El agente intercepta, en el momento de carga de clases, los puntos de entrada y salida de más de ochenta bibliotecas populares —JDBC, clientes HTTP, Kafka, gRPC— e inyecta código de rastreo sin que el desarrollador modifique una sola línea de su aplicación. Es uno de los ejemplos más concretos de AOP operando a escala global en producción.

Hoy AOP es un paradigma omnipresente pero frecuentemente invisible. Según el informe State of Developer Ecosystem 2023 de JetBrains, Spring Boot es utilizado por más del 62% de los desarrolladores Java a nivel mundial, lo que convierte a AOP en uno de los paradigmas con mayor presencia efectiva en la industria, aunque raramente sea nombrado como tal por quienes lo usan a diario.


Cristina Lopes comenzó a trabajar con Kickzales y su grupo, eventualmente dejaron de lado a programación adaptativa para, a partir de la misma, crear la programación orientada a aspectos

Otra persona que contribuyó a Gregor Kickzales fue Mira Mezini. Ella trabajó con el en la creción del documento "Aspect-Oriented Programming and Modular Reasonning" donde se habla a cabalidad sobre la POA, y la implementación de módulos en el código. Además de eso, actualmente trabaja en la implementación de la Programación Orientada a Aspectos en Bases de Datos.

La programación orientada a aspectos es un paradigma muy joven, pero promete un gran potencial, tanto que se dice que la programación orientada a aspectos podría ser un nuevo salto en las generaciones de la ingeniería de software.

Referencias (aporte 2026-1)