¿Qué alternativas existen para las preocupaciones transversales además de la programación orientada a aspectos? [cerrado]

La programación orientada a aspectos promete lidiar con preocupaciones transversales, pero todavía no estoy completamente convencido. ¿Ha habido otros intentos de tratar este problema?

Cuando sea posible, puede encapsular las preocupaciones transversales en módulos separados que luego se utilizan en toda la aplicación a través de la inyección de dependencia. Esto le permite desacoplar un poco la implementación de la preocupación transversal de su uso en todo el código.

Sin embargo, esto no siempre funciona con elegancia. Esa es la razón por la cual las personas están tratando de abordar el problema con cosas como AOP.

Otras dos opciones que aún no he visto exploradas:

Programación funcional con mónadas y flechas

En FP, representa una preocupación transversal como cualquier otra cosa: como algo que pasa en una llamada de función. Dado que hacerlo explícitamente se vuelve tedioso, puede usar Mónadas (o tal vez Flechas) para ocultar la información adicional que se transmite.

El ejemplo más común de AOP es el registro. Con Monads, crearía una mónada "Logger" que mantiene una lista de mensajes. Cualquier función que realice a través de LoggerMonad tiene la capacidad de publicar un mensaje de registro. Con Arrows, modelaría todo el flujo de datos de la aplicación y trabajaría una rutina de registro en el modelo cuando sea apropiado. Yo creo que. Las flechas son bastante complejas.

Programación basada en entidades / componentes

Algo que he estado investigando y experimentando para un motor de juego. En lugar de "objetos" como en OOP, descompone todo en paquetes de datos (componentes) y servicios que operan sobre un tipo de componente. Los componentes se agrupan por ID comunes, como en una base de datos relacional, y los grupos de componentes vinculados son las Entidades. Para agregar el registro en un sistema de este tipo, debe agregar un nuevo servicio de registro de los desencadenantes en función de los componentes que se pasan a través de él.

Ambos métodos permiten trabajar fácilmente un cambio transversal muy fácilmente, pero ambos son modelos arquitectónicos de alto nivel. Por lo tanto, probablemente deba usarlos desde el principio. El modelo de componentes puede, en teoría, trabajarse en un sistema OOP existente. Supongo que las mónadas también podrían serlo si tu idioma es lo suficientemente poderoso.

Hay varias formas de abordar los problemas de las preocupaciones transversales:

• Utilice mejores patrones de diseño, expresiones idiomáticas o mecanismos de abstracción : el código puede ser transversal aunque se pueda modularizar. Para mantener el código, deberá refactorizar para utilizar la técnica de diseño que puede modularizarlo. Tal refactorización puede introducir cortes transversales de un tipo diferente, pero es de esperar que los cortes transversales sean estables y que probablemente no cambien.

• Desarrolle características de lenguaje más ricas : muchas manifestaciones de corte transversal se pueden resolver a través de mejores mecanismos de abstracción, y algunas veces son necesarias nuevas características de lenguaje. Por ejemplo, los lenguajes más avanzados que incluyen características funcionales y orientadas a objetos a menudo no emplean tantos patrones de diseño, porque no son necesarios. Tenga en cuenta que los patrones de diseño en sí pueden ser de naturaleza transversal , ya que describen los roles de varios objetos y clases diferentes. En Java, la reflexión a menudo se puede usar en lugar de un aspecto, aunque a un costo de tiempo de ejecución más alto. Por ejemplo, utilizando la reflexión, puede admitir el patrón de visitante en cientos de clases con solo un par de líneas de código. La biblioteca de DJfrom Northeastern es una solución reflexiva que hace exactamente eso. Los mixins son una técnica poderosa disponible en C ++ (pero no en Java) y pueden darle algunos de los mismos casos de uso como aspecto.

• Proporcione un mejor soporte de herramientas : las técnicas como el uso grepy la realización de operaciones de refactorización pueden resolver problemas relacionados con el código transversal. Por ejemplo, el nombre de un método declarado en una interfaz puede atravesar el programa. (Tenga en cuenta la diferencia técnica aquí: es el nombre del método, no la implementación del método, los cortes transversales). Esto generalmente no es un problema en un IDE como Eclipse, donde puede usar la "refactorización de cambio de nombre" para cambiar todo los lugares en su código que usan el nombre. De esta manera, es posible que no necesite funciones de lenguaje cuando el entorno de programación es lo suficientemente expresivo para usted.

• Utilice lenguajes específicos de dominio : los primeros lenguajes de aspecto, anteriores a AspectJ, eran específicos de dominio y se aplicaban solo a ciertos problemas, como la sincronización de hilos o el análisis de flujo de datos para combinar eficientemente las composiciones de funciones. Estos lenguajes eran experimentales, pero parecían altamente exitosos en modularizar preocupaciones que de otro modo serían transversales.

• Use técnicas de programación generativa : avanzar al meta nivel podría considerarse una técnica de implementación para la programación orientada a aspectos, pero es un área lo suficientemente grande como para trascender aspectos simples. Las técnicas generativas (donde un programa genera código fuente para otro programa) también están relacionadas con lenguajes específicos de dominio.

Por todo esto, creo que estudiar AOP es apropiado. AOP puede ayudarlo a expandir sus conceptos de código, incluso si no usa un lenguaje AOP.

En general, etiquetar elementos de código con una característica declarativa, pero específicamente el sistema de atributos en el mundo C # /. NET / Mono.

No soy un experto en AOP, pero al leerlo a lo largo de los años, siempre me ha parecido una forma más débil de la metaprogramación ofrecida por Lisp , especialmente partes como su protocolo de metaobjetos.

Supongo que esto no debería sorprendernos: Gregor Kiczales fue uno de los autores de AMOP, y más tarde escribió AspectJ para Java.