Programación Orientada a Aspectos vs. Programación Orientada a Objetos

Question

Como la mayoría de los desarrolladores aquí y en todo el mundo, he estado desarrollando sistemas de software que utilizan técnicas de programación orientada a objetos (OOP) durante muchos años. Entonces, cuando leo que la programación orientada a aspectos (AOP) aborda muchos de los problemas que la OOP tradicional no resuelve completa o directamente, me detengo y pienso, ¿es real?

He leído mucha información al intentar aprender las claves de este paradigma AOP y estoy en el mismo lugar, por lo que quería entender mejor sus beneficios en el desarrollo de aplicaciones en el mundo real.

¿Alguien tiene la respuesta?

Answer 1

¿Por qué " vs " ;? No es " vs " ;. Puede usar la programación Orientada a Aspectos en combinación con la programación funcional, pero también en combinación con la Orientada a Objetos. No es "vs", es "Programación orientada a aspectos con Programación orientada a objetos".

Para mí, AOP es una especie de metaprogramación. Todo lo que hace AOP también se puede hacer sin él simplemente agregando más código. AOP solo te ahorra al escribir este código.

Wikipedia tiene uno de los mejores ejemplos para esta meta-programación. Suponga que tiene una clase gráfica con muchos '' set ... () '' metodos Después de cada método de ajuste, los datos de los gráficos cambiaron, por lo tanto los gráficos cambiaron y, por lo tanto, los gráficos deben actualizarse en la pantalla. Supongamos que vuelve a pintar los gráficos a los que debe llamar " Display.update () " ;. El enfoque clásico es resolver esto agregando más código . Al final de cada método establecido, escribe

void set...(...) {
    :
    :
    Display.update();
}

Si tienes 3 métodos set, eso no es un problema. Si tiene 200 (hipotético), se está volviendo realmente doloroso agregar esto en todas partes. Además, cada vez que agregue un nuevo método set, debe asegurarse de no olvidar agregar esto al final, de lo contrario, simplemente creó un error.

AOP resuelve esto sin agregar toneladas de código, en lugar de eso, agrega un aspecto:

after() : set() {
   Display.update();
}

¡Y eso es todo! En lugar de escribir el código de actualización usted mismo, simplemente le dice al sistema que después de alcanzar un punto de corte set (), debe ejecutar este código y ejecutará este código. No es necesario actualizar 200 métodos, no es necesario asegurarse de no olvidar agregar este código en un nuevo método de configuración. Además solo necesita un punto de corte:

pointcut set() : execution(* set*(*) ) && this(MyGraphicsClass) && within(com.company.*);

¿Qué significa eso? Eso significa que si un método se denomina " conjunto * " (* significa que cualquier nombre puede seguir después del conjunto), independientemente de lo que devuelva el método (primer asterisco) o qué parámetros toma (tercer asterisco) y es un método de MyGraphicsClass y esta clase es parte del paquete '' com.company. * '', entonces este es un punto de corte set (). Y nuestro primer código dice " después de ejecutar cualquier método que sea un punto de corte establecido, ejecute el siguiente código " ;.

¿Ves cómo AOP resuelve elegantemente el problema aquí? En realidad, todo lo descrito aquí se puede hacer en tiempo de compilación. Un preprocesador de AOP puede simplemente modificar su fuente (por ejemplo, agregar Display.update () al final de cada método de set-pointcut) incluso antes de compilar la clase en sí.

Sin embargo, este ejemplo también muestra uno de los grandes inconvenientes de AOP. En realidad, AOP está haciendo algo que muchos programadores consideran un " Anti-Pattern " ;. El patrón exacto se llama " Acción a distancia " ;.png

  

La acción a distancia es un   anti-patrón (un común reconocido   error) en el que el comportamiento en una parte   de un programa varía mucho según   difícil o imposible de identificar   Operaciones en otra parte de la   programa.

Como novato en un proyecto, podría leer el código de cualquier método set y considerarlo roto, ya que parece que no actualiza la pantalla. No veo simplemente mirando el código de un método set, que después de que se ejecute, algún otro código "mágicamente" Se ejecutará para actualizar la pantalla. Considero que esto es un serio inconveniente! Al realizar cambios en un método, podrían introducirse errores extraños. Comprender mejor el flujo de código del código donde ciertas cosas parecen funcionar correctamente, pero no son obvias (como dije, simplemente funcionan mágicamente ... de alguna manera), es realmente difícil.

Actualizar

Solo para aclarar que: Algunas personas pueden tener la impresión de que estoy diciendo que AOP es algo malo y que no debe usarse. ¡Eso no es lo que estoy diciendo! AOP es en realidad una gran característica. Solo digo "uso cuidadosamente". El AOP solo causará problemas si mezcla el código normal y el AOP para el mismo Aspecto . En el ejemplo anterior, tenemos el aspecto de actualizar los valores de un objeto gráfico y pintar el objeto actualizado. Eso es, de hecho, un solo aspecto. Codificar la mitad como código normal y la otra mitad como aspecto es lo que agrega el problema.

Si usa AOP para un aspecto completamente diferente, p. para iniciar sesión, no se encontrará con el problema antipatrón. En ese caso, un novato en el proyecto podría preguntarse "¿De dónde vienen todos estos mensajes de registro? No veo ninguna salida de registro en el código '', pero eso no es un gran problema. Los cambios que realiza en la lógica del programa difícilmente romperán la instalación del registro y los cambios realizados en la instalación del registro difícilmente romperán la lógica del programa: estos aspectos están totalmente separados. El uso de AOP para el registro tiene la ventaja de que el código de su programa puede concentrarse completamente en hacer lo que sea que deba hacer y aún así puede tener un registro sofisticado, sin que su código esté abarrotado por cientos de mensajes de registro en todas partes. Además, cuando se introduce un nuevo código, los mensajes de registro mágico aparecerán en el momento correcto con el contenido correcto. Es posible que el programador novato no entienda por qué están allí o de dónde provienen, pero dado que registrarán lo "correcto". en el momento adecuado, puede aceptar felizmente el hecho de que están allí y pasar a otra cosa.

Entonces, un buen uso de AOP en mi ejemplo sería siempre registrar si algún valor ha sido actualizado a través de un método establecido. Esto no creará un antipatrón y casi nunca será la causa de ningún problema.

Se podría decir que si puede abusar fácilmente de AOP para crear tantos problemas, es una mala idea usarlo todo. Sin embargo, ¿qué tecnología no se puede abusar? Puede abusar de la encapsulación de datos, puede abusar de la herencia. Se puede abusar de casi todas las tecnologías de programación útiles. Considere un lenguaje de programación tan limitado que solo contiene características que no se pueden abusar; un idioma en el que las funciones solo se pueden utilizar como se pretendía utilizar inicialmente. Tal lenguaje sería tan limitado que es discutible si se puede usar incluso para la programación del mundo real.

Answer 2

OOP y AOP no se excluyen mutuamente. AOP puede ser una buena adición a la POO. AOP es especialmente útil para agregar código estándar como registro, seguimiento de rendimiento, etc. a métodos sin obstruir el código del método con este código estándar.

Answer 3

la programación orientada a aspectos proporciona una buena forma de implementar problemas transversales como el registro y la seguridad. Estas conferencias transversales son piezas de lógica que deben aplicarse en muchos lugares, pero en realidad no tienen nada que ver con la lógica empresarial.

No deberías ver AOP como un reemplazo de OOP, más como un buen complemento, que hace que su código sea más limpio, débilmente acoplado y centrado en la lógica empresarial. Entonces, al aplicar AOP, obtendrás 2 beneficios principales:

1. La lógica para cada preocupación está ahora en un solo lugar, en lugar de estar dispersa por todo el código base.

2. las clases son más limpias ya que solo contienen código para su principal preocupación (o funcionalidad principal) y las secundarias se han trasladado a aspectos.

Answer 4

Creo que no hay una respuesta general a esta pregunta, pero una cosa que se debe tener en cuenta es que el AOP no reemplaza OOP, sino que agrega ciertas características de descomposición que abordan la llamada tiranía de la composición dominante ( 1 ) (o inquietudes transversales).

Seguramente ayuda en ciertos casos, siempre y cuando tenga el control de las herramientas y los idiomas que se utilizarán para un proyecto específico, pero también agrega un nuevo nivel de complejidad con respecto a la interacción de aspectos y la necesidad de herramientas adicionales como < a href = "http://www.eclipse.org/ajdt" rel = "nofollow noreferrer"> AJDT para entender aún más su programa.

Gregor Kiczales una vez dio una interesante charla introductoria sobre AOP en Google Tech Talks, que recomiendo ver: Programación Orientada a Aspectos: Investigación Radical en Modularidad .

Answer 5

En primer lugar, el AOP no reemplazará la POO. AOP extiende OOP. Las ideas y prácticas de la OOP se mantienen relevantes. Tener un buen diseño de objetos probablemente hará que sea más fácil extenderlo con aspectos.

Creo que las ideas que trae AOP son importantes. Necesitamos encontrar maneras de implementar preocupaciones transversales sobre diferentes clases en su programa sin tener que cambiar las clases por sí mismas. Pero creo que el AOP eventualmente se convertirá en parte de otras herramientas que utilizamos y no en una herramienta o técnica por separado. Ya vemos que esto sucede.

Un par de lenguajes dinámicos como Ruby y Python tienen construcciones de lenguaje como mixins que resuelven los mismos problemas. Esto se parece mucho a AOP pero está mejor integrado en el lenguaje.

Spring and Castle y un par de otros marcos de inyección de dependencias tienen opciones para agregar comportamiento a las clases que inyectan. Esta es una forma de tejer en tiempo de ejecución y creo que tiene un gran potencial.

No creo que tengas que aprender un paradigma completamente nuevo para usar AOP. Las ideas son interesantes pero están siendo absorbidas lentamente por las herramientas y los idiomas existentes. Solo manténgase informado y pruebe estas herramientas.

Answer 6

AOP es un nuevo paradigma de programación que trata este concepto. Un aspecto es una entidad de software que implementa una parte específica no funcional de la aplicación.

Creo que este artículo es un buen lugar para comenzar con la programación orientada a aspectos: http://www.jaftalks.com/wp/ index.php / introduction-to-aspect-orientado a programación /

Answer 7

OOP se utiliza principalmente para organizar su lógica empresarial mientras que AOP ayuda a organizar sus elementos no funcionales como auditoría, registro, gestión de transacciones, seguridad, etc.

De esta manera puede desacoplar su lógica empresarial con una lógica no ficticia que hace que el código sea más limpio.

La ventaja de Otter es que puede aplicar el consejo (ejemplo de auditoría) de manera muy consistente sin implementar ninguna interfaz que ofrezca una gran flexibilidad para la modificación sin tocar la lógica empresarial