ventajas programming programacion paradigma oriented orientado orientada objetos eventos desventajas caracteristicas aspectos oop aop paradigms

oop - programming - programacion orientada a eventos



Programación Orientada a Aspectos vs. Programación Orientada a Objetos (6)

Al igual que la mayoría de los desarrolladores aquí y en todo el mundo, he estado desarrollando sistemas de software utilizando 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 completamente o directamente, hago una pausa y pienso: ¿es real?

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

¿Alguien tiene la respuesta?

¿Por qué "vs"? No es "vs". Puede utilizar 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 "meta-programación". Todo lo que hace AOP también podría hacerse sin él simplemente agregando más código. AOP simplemente te ahorra escribir este código.

Wikipedia tiene uno de los mejores ejemplos para esta meta-programación. Supongamos que tiene una clase gráfica con muchos métodos "set ... ()". Después de cada método de configuración, 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. Asuma que volver a pintar los gráficos debe llamar a "Display.update ()". El enfoque clásico es resolver esto agregando más código . Al final de cada método de conjunto, escriba

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

Si tienes 3 set-methods, eso no es un problema. Si tienes 200 (hipotético), es muy doloroso agregar esto a todos lados. También cada vez que agrega un nuevo set-method, debe asegurarse de no olvidar agregar esto al final, de lo contrario, acaba de crear un error.

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

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

¡Y eso es! En lugar de escribir usted mismo el código de actualización, simplemente le dice al sistema que después de que se ha alcanzado 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 set-method. Además, solo necesitas un punto de corte:

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

Qué significa eso? Eso significa que si un método se llama "set *" (* significa que cualquier nombre puede seguir después del conjunto), independientemente de lo que devuelve el método (primer asterisco) o qué parámetros toma (tercer asterisco) y es un método de MyGraphicsClass y esto class es parte del paquete "com.company. *", luego 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".

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

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

La acción a distancia es un antipatrón (un error común reconocido) en el que el comportamiento en una parte del programa varía enormemente según las operaciones difíciles o imposibles de identificar en otra parte del programa.

Como novato en un proyecto, podría leer el código de cualquier conjunto de métodos y considerarlo roto, ya que parece que no actualiza la pantalla. No veo con solo mirar el código de un set-method, que después de que se ejecute, algún otro código se ejecutará "mágicamente" para actualizar la pantalla. ¡Considero que esto es un inconveniente serio! Al hacer cambios en un método, pueden introducirse errores extraños. Comprender mejor el código de flujo de 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 eso: Algunas personas pueden tener la impresión de que estoy diciendo que AOP es algo malo y no debe usarse. ¡Eso no es lo que estoy diciendo! AOP es realmente una gran característica. Solo digo "Úselo con cuidado". 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. De hecho, es un aspecto único. Codificar la mitad como código normal y la otra mitad como aspecto es lo que agrega el problema.

Si utiliza AOP para un aspecto completamente diferente, por ejemplo, para el registro, 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 ningún resultado de registro en el código", pero ese no es un gran problema. Los cambios que realice en la lógica del programa apenas romperán la función de registro y los cambios realizados en la función de registro difícilmente romperán su lógica de programa; estos aspectos están totalmente separados. Usar AOP para el registro tiene la ventaja de que su código de programa puede concentrarse completamente en hacer lo que debe hacer y aún puede tener un registro sofisticado, sin que su código se vea saturado por cientos de mensajes de registro en todas partes. Además, cuando se introduce un nuevo código, los mensajes de registro mágicamente aparecerán en el momento adecuado con el contenido correcto. El programador novato podría no entender por qué están allí o de dónde vienen, pero dado que registrarán lo "correcto" en el "momento adecuado", él 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 registrar siempre si algún valor se ha 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 puedes abusar fácilmente del 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 contenga características que no se pueden abusar; un idioma en el que las características solo se pueden utilizar tal como estaban destinadas inicialmente a ser utilizadas. Tal lenguaje sería tan limitado que es discutible si puede usarse incluso para la programación del mundo real.

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

Seguramente ayuda en ciertos casos, siempre y cuando tenga el control de las herramientas y los lenguajes que utilizará 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 el AJDT para comprender tu programa

Gregor Kiczales dio una charla introductoria interesante sobre AOP en Google Tech Talks que recomiendo observar: Programación orientada a aspectos: Investigación radical en modularidad .

En primer lugar, AOP no reemplazará OOP. AOP extiende OOP. Las ideas y prácticas de OOP siguen siendo relevantes. Tener un buen diseño de objeto probablemente hará que sea más fácil extenderlo con aspectos.

Creo que las ideas que aporta AOP son importantes. Necesitamos encontrar formas 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 usamos y no en una herramienta o técnica separada. 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 y Castle y un par de frameworks de inyección de dependencia tienen opciones para agregar comportamiento a las clases que inyectan. Esta es una forma de trabajar en tiempo de ejecución y creo que tiene mucho potencial.

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

La pogramación orientada a los aspectos proporciona una buena manera de implementar cuestiones transversales como el registro, la seguridad. Estas conceptualizaciones transversales son piezas de lógica que deben aplicarse en muchos lugares pero que en realidad no tienen nada que ver con la lógica comercial.

No debería ver el AOP como un reemplazo de OOP, más como un complemento agradable, que hace que su código sea más limpio, sin acoplamiento y centrado en la lógica de negocios. Entonces al aplicar AOP obtendrás 2 beneficios principales:

  1. La lógica para cada preocupación ahora está en un lugar, en lugar de dispersarse por toda la base del código.

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

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