it-swarm-es.com

¿Qué alternativas existen para las preocupaciones transversales aparte de la programación orientada a aspectos?

La programación orientada a aspectos promete lidiar con preocupaciones transversales, pero todavía no estoy completamente convencido. ¿Ha habido algún otro intento de solucionar este problema?

20
Casebash

Cuando sea posible, puede encapsular las preocupaciones transversales en módulos separados que luego se utilizan en toda la aplicación mediante 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.

8
Fishtoaster

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

Programación funcional con mónadas y flechas

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

El ejemplo más común de AOP es el registro. Con Mónadas, 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 inicio de sesión en un sistema de este tipo, debe agregar un nuevo servicio de inicio de sesión basado en 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 existente OOP. Supongo que las mónadas también podrían funcionar si su lenguaje es lo suficientemente potente.

6
CodexArcanum

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

  • Utilice mejores patrones de diseño, modismos 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 pueden resolverse 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í mismos pueden ser transversales en la naturaleza, porque 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 DJ de Northeastern es una solución reflexiva que hace exactamente eso. Mixins es una técnica poderosa disponible en C++ (pero no en Java) y puede darle algunos de los mismos casos de uso como aspecto.

  • Proporcione un mejor soporte de herramientas : Las técnicas como el uso de grep y la realización de operaciones de refactorización pueden resolver problemas relacionados con el código de corte 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 todos 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.

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

  • Usar técnicas de programación generativa : Ascender al nivel meta podría considerarse una técnica de implementación para la programación orientada a aspectos, pero es un área lo suficientemente grande que trasciende 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.

3
Macneil

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

2
mumtaz

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 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 luego escribió AspectJ para Java.

2
Ken