El significado del nombre AOP
El nombre "programación orientada a aspectos" no es fácil de entender y puede confundirse fácilmente. El autor ha escuchado más de una vez discursos similares a "OOP/OOD11 pronto quedará obsoleto, AOP es una nueva generación de métodos de desarrollo de software". Obviamente, el hablante no entendió el significado de AOP. Aspecto, sí, significa "aspecto". En la semántica tradicional china, "ti" se refiere principalmente a las características de un objeto en diferentes dimensiones o ángulos. Por ejemplo, solemos decir: "Este asunto hay que verlo desde varios aspectos", lo que muchas veces significa que lo mismo hay que verlo desde diferentes ángulos. El "estado" aquí se refiere a las características externas de las cosas reflejadas desde diferentes ángulos de visión. En AOP, el significado de Aspecto puede entenderse más apropiadamente como "aspecto". Por tanto, el autor prefiere la traducción de "programación orientada a secciones".
Una tecnología que puede agregar funcionalidad dinámica y uniformemente a un programa sin modificar el código fuente mediante precompilación y servidores proxy dinámicos en tiempo de ejecución. AOP es en realidad una continuación del patrón de diseño GoF. Los patrones de diseño buscan incansablemente el desacoplamiento entre las personas que llaman y los destinatarios para mejorar la flexibilidad y escalabilidad del código. Se puede decir que AOP es la realización de este objetivo.
Spring proporciona un amplio soporte para la programación orientada a aspectos, lo que permite un desarrollo coherente al separar la lógica empresarial de una aplicación de los servicios a nivel del sistema, como la auditoría y la gestión de transacciones. Los objetos de aplicación hacen lo que se supone que deben hacer (lógica empresarial completa) y nada más. No son responsables (ni siquiera conocen) otros problemas a nivel del sistema, como el registro o el soporte de transacciones. Aunque AOP y OOP son literalmente muy similares, son dos ideas de diseño para campos diferentes. La POO (Programación Orientada a Objetos) abstrae y encapsula las entidades de los procesos de negocio y sus atributos y comportamientos para obtener una división de unidades lógicas más clara y eficiente.
AOP extrae aspectos del proceso de negocio y se orienta a un determinado paso o etapa del proceso para obtener un efecto de aislamiento de bajo acoplamiento entre varias partes del proceso lógico. Estas dos ideas de diseño tienen diferencias esenciales en los objetivos.
La afirmación anterior puede ser demasiado teórica. Para dar un ejemplo simple, encapsular una entidad comercial, como "empleado", es naturalmente una tarea OOP/OOD. Podemos crear una clase de "empleado" para ello, encapsulando las propiedades y comportamientos relacionados con "empleado". Es imposible encapsular a los "empleados" con ideas de diseño de AOP.
Del mismo modo, la división de fragmentos de acción de "verificación de permisos" es también el campo objetivo de AOP. Sin embargo, encapsular una acción a través de OOD/OOP es un poco anodino.
En otras palabras, OOD/OOP está orientado al dominio sustantivo y AOP está orientado al dominio verbal. Cuando muchas personas entran en contacto por primera vez con AOP, pueden decir que lo que AOP puede hacer se puede lograr mediante una interfaz OOP bien definida. Creo que vale la pena debatir esta opinión. Se puede decir que la interfaz entre AOP y OOP bien definida son dos formas de resolver e implementar problemas transversales en los requisitos. Pero para la interfaz en OOP, todavía requiere que llamemos a los métodos relevantes en el módulo correspondiente. Esto es inevitable en OOP. Una vez que se modifica la interfaz, todo se convertirá en un desastre, solo es necesario. para modificar el aspecto correspondiente basta con volver a tejerlo. Por supuesto, AOP nunca reemplazará a OOP. Los requisitos básicos seguirán siendo implementados por OOP, y AOP se integrará con OOP para complementarse entre sí.