¿Cuál es la diferencia entre ioc y aop?
1 IoC, (Inverse of Control) Inversión de Control, que contiene dos contenidos: uno es control y el otro es inversión. En un programa, el control de la selección de la clase llamada se elimina de la clase que llama y se transfiere a un tercero para su adjudicación. Este tercero se refiere al contenedor Spring. Otra explicación de IoC es la inyección de dependencia. La dependencia de la clase que llama con la clase llamada es inyectada por un tercero para eliminar la referencia de la clase que llama a la clase llamada.
2 aop, programación orientada a aspectos (también llamada programación orientada a aspectos): la programación orientada a aspectos (AOP) es un punto importante en el desarrollo de software actual y un contenido importante en el marco Spring. AOP se puede utilizar para aislar varias partes de la lógica empresarial, reduciendo así el acoplamiento entre las distintas partes de la lógica empresarial, mejorando la reutilización del programa y mejorando la eficiencia del desarrollo.
3 AOP es la continuación de OOP y es la abreviatura de (Aspect Oriented Programming), que significa programación orientada a aspectos. Las funciones principales son: registro, estadísticas de rendimiento, control de seguridad, procesamiento de transacciones, manejo de excepciones, etc.
4 La intención principal es separar el registro, las estadísticas de rendimiento, el control de seguridad, el procesamiento de transacciones, el manejo de excepciones y otros códigos del código de lógica empresarial. Al separar estos comportamientos, esperamos separarlos en métodos que. no guíe la lógica empresarial y luego cambie estos comportamientos sin afectar el código de la lógica empresarial.
Información ampliada:
IoC es un concepto amplio y se puede implementar de diferentes maneras. Hay dos formas principales:
Búsqueda de dependencias: el contenedor proporciona interfaces de devolución de llamada y condiciones contextuales a los componentes. Tanto EJB como Apache Avalon utilizan este enfoque. De esta manera, el componente debe usar la API proporcionada por el contenedor para encontrar recursos y objetos colaborativos. La única inversión de control solo se refleja en esos métodos de devolución de llamada (es decir, el tipo 1 mencionado anteriormente): el contenedor llamará a estos métodos de devolución de llamada. Esto permite que el código de la aplicación obtenga recursos relevantes.
Inyección de dependencia: el componente no realiza consultas de posicionamiento, solo proporciona métodos Java ordinarios para permitir que el contenedor determine las dependencias. El contenedor es el único responsable del ensamblaje de los componentes. Pasará objetos que cumplan con las dependencias de los objetos requeridos a través de propiedades o constructores de JavaBean. La práctica de inyectar dependencias a través de propiedades de JavaBean se llama Setter Inyección; la práctica de pasar dependencias como parámetros del constructor se llama Constructor Inyección
Implementación de la capa de acceso a datos
La capa de acceso a datos tiene dos objetivos. La primera es abstraer el motor de la base de datos de la aplicación para que la base de datos pueda cambiarse en cualquier momento (por ejemplo, de Microsoft SQL a Oracle). Sin embargo, esto rara vez se hace en la práctica y no hay razones suficientes para realizar esfuerzos futuros para refactorizar las aplicaciones existentes mediante la implementación de una capa de acceso a datos.
El segundo objetivo es abstraer el modelo de datos de la implementación de la base de datos. Esto permite cambiar la base de datos o el código según sea necesario y afectar solo a una pequeña parte de la aplicación principal: la capa de acceso a datos. Este objetivo merece la refactorización necesaria para implementarlo en los sistemas existentes.
Refactorización de módulos e interfaces
Una idea central detrás de la inyección de dependencia es el principio de responsabilidad única. Este principio establece que cada objeto debe tener un propósito específico y que las diferentes partes de la aplicación que necesitan explotar ese propósito deben utilizar objetos apropiados. Esto significa que estos objetos se pueden reutilizar en cualquier parte del sistema. Pero este no es el caso en muchos sistemas existentes.
Agregue pruebas unitarias en cualquier momento
Encapsular funciones en el objeto completo hará que las pruebas automáticas sean difíciles o imposibles.
La refactorización de esta manera permite realizar pruebas unitarias más avanzadas al aislar módulos e interfaces de objetos específicos. Es tentador continuar refactorizando un módulo con la idea de agregar pruebas más adelante, pero esto es un error.
Utilice localizadores de servicios en lugar de inyección de constructor
Existe más de una forma de lograr la inversión de control. El enfoque más común es utilizar la inyección de constructor, que requiere que se proporcionen todas las dependencias del software cuando se crea el objeto por primera vez. Sin embargo, la inyección de construcciones supone que todo el sistema utiliza este patrón, lo que significa que todo el sistema debe refactorizarse simultáneamente. Es difícil, arriesgado y requiere mucho tiempo.
Aunque AOP y OOP son muy similares literalmente, son dos ideas de diseño para campos diferentes. POO (Programación Orientada a Objetos) encapsula de forma abstracta las entidades y sus atributos y comportamientos del proceso de procesamiento de negocios para obtener una división de unidades lógicas más clara y eficiente.
AOP extrae aspectos del proceso de procesamiento empresarial. Se ocupa de un determinado paso o etapa del proceso de procesamiento para obtener un bajo acoplamiento entre las distintas partes del proceso lógico. Estas dos ideas de diseño tienen objetivos esencialmente diferentes.
La declaración anterior puede ser demasiado teórica. Para dar un ejemplo simple, encapsular una entidad comercial como "empleado" es, naturalmente, una tarea de POO/OOD. Podemos crear una clase "Empleado". y encapsula atributos y comportamientos relacionados con los "empleados". Será imposible encapsular a los "empleados" con ideas de diseño de AOP.
De manera similar, dividir el segmento de acción de "verificación de autoridad" es el área objetivo de AOP. Encapsular una acción a través de OOD/OOP es un poco anodino.
En otras palabras, OOD/OOP está orientado al campo sustantivo y AOP está orientado al campo verbal.
La programación orientada a procesos ya está muy lejos de nosotros, y la programación orientada a objetos está dominando el mundo del software. Cuando se requiere que cada nuevo diseñador de software domine cómo convertir las funciones requeridas en clases y definir sus miembros de datos, comportamientos y relaciones complejas entre ellos, la programación orientada a aspectos (Programación Orientada a Aspectos, AOP) nos trae nuevas ideas, nuevos pensamientos, y nuevos modelos.
Si la programación orientada a objetos se ocupa de dividir las funciones requeridas en clases diferentes y relativamente independientes, clases bien encapsuladas y permitirles tener sus propios comportamientos, confiando en la herencia y el polimorfismo para definir sus relaciones. Si es así Luego, la programación orientada a aspectos espera separar las funciones requeridas comunes de las clases no relacionadas, de modo que muchas clases puedan compartir un comportamiento, una vez que ocurre un cambio, no es necesario modificar muchas clases, solo se puede modificar el comportamiento.
La programación orientada a aspectos es un nuevo paradigma apasionante. En lo que respecta al desarrollo de sistemas de software, su influencia seguramente será tan grande como la programación orientada a objetos, que tiene décadas de historia de aplicaciones. La programación orientada a aspectos y la programación orientada a objetos no sólo no son tecnologías competitivas, sino que también son muy complementarias entre sí.
La programación orientada a objetos se utiliza principalmente para modelar comportamientos comunes en el mismo nivel de objeto. Su debilidad es la aplicación del comportamiento público a través de múltiples modelos de objetos no relacionados. Y aquí es exactamente donde encaja la programación orientada a aspectos. Con AOP, podemos definir relaciones transversales y aplicar estas relaciones a modelos de objetos que difieren entre sí en todos los módulos. AOP también nos permite superponer funcionalidades en lugar de incrustarlas, lo que hace que el código sea más legible y más fácil de mantener. Funcionará bien con programación orientada a objetos.
Materiales de referencia: Enciclopedia Baidu-aop? Enciclopedia Baidu-ioc