Comentarios de Sping, COI y AOP
Clase A{
AInterfaz a;
A(){}
aMethod(){
a = new AInterfaceImp();
}
}
ClassA y AInterfaceImp son dependencias, por lo que si quiero Usar otra implementación de AInterface requiere modificar el código. Por supuesto, podemos crear una fábrica para generar la implementación específica de AInterface que queremos en función de las condiciones, es decir,
InterfaceImplFactory{
AInterface create(Object condition){
if(condición = condA){
devuelve nueva AInterfaceImpA();
}elseif(condición = condB){
devuelve nueva AInterfaceImpB();
}else{
devolver nuevo AInterfaceImp();
}
}
}
}
En la superficie, esto alivia los problemas anteriores hasta cierto punto, pero esencialmente este acoplamiento de código no ha cambiado. El patrón IoC puede resolver completamente este problema de acoplamiento. Puede eliminar el acoplamiento en el código, colocarlo en un archivo XML unificado y formar dependencias a través del contenedor cuando sea necesario, es decir, inyectar la implementación de interfaz requerida en la clase que la necesita. , que puede ser el origen del término "inyección de dependencia".
El patrón IOC separa la configuración de la aplicación y las especificaciones de dependencia del código de la aplicación real mediante la introducción de un contenedor IOC que implementa el patrón IOC, lo que permite que el contenedor IOC administre el ciclo de vida de los objetos, las dependencias, etc. Una de sus características es la configuración de interrelaciones entre los componentes de la aplicación a través de archivos adjuntos de texto sin necesidad de volver a modificar y compilar código específico.
Actualmente, los contenedores IOC más famosos incluyen Pico Container, Avalon, Spring, JBoss, HiveMind, EJB, etc.
Entre los contenedores IOC mencionados anteriormente, los livianos incluyen Pico Container, Avalon, Spring, HiveMind, etc., los súper pesados incluyen EJB, y los contenedores semiligeros y semipesados incluyen JBoss, Jdon , etc. .
El modelo IoC puede verse como una sublimación del modelo de fábrica. IoC puede verse como una gran fábrica, pero todos los objetos que generará esta gran fábrica se definen en archivos XML y luego se usan. La programación Java "Reflection" genera el objeto correspondiente en función del nombre de clase dado en XML. Bienvenido a la red de aprendizaje, recopile este artículo [1] [2]
$False$
Desde una perspectiva de implementación, IoC es un código de generación de objetos que codifica la fábrica anterior. método, en lugar de definirlo mediante archivos XML, es decir, la fábrica y la generación de objetos se separan de forma independiente, para mejorar la flexibilidad y la capacidad de mantenimiento.
La tecnología Java más básica en IoC es la programación "reflexiva". La reflexión es un término difícil de entender, pero en términos sencillos, la reflexión es el proceso de generar un objeto basado en un nombre de clase determinado (una cadena). Esta forma de programación le permite decidir qué tipo de objeto se genera cuando se genera el objeto.
La reflexión se usa ampliamente. Por ejemplo, Hibernate y String usan "reflexión" como el medio técnico más básico.
En el pasado, la programación reflexiva era 10 veces más lenta que la generación normal de objetos, lo que puede explicar por qué la reflexión no se usa comúnmente. Sin embargo, después de las mejoras y optimizaciones de SUN, la diferencia de velocidad entre la reflexión y la generación normal de objetos no es tan grande (pero sigue siendo más del doble).
¿Cuál es la mayor ventaja de IoC? Debido a que la generación de objetos está definida en XML, se vuelve muy simple cuando necesitamos cambiar la implementación de una determinada subclase (en términos generales, dichos objetos son algún tipo de interfaz en realidad), siempre que en XML Simplemente cámbielo, entonces incluso podemos conectar objetos en caliente (algo así como interfaces USB y discos duros SCIS).
¿Cuál es la mayor desventaja del IoC? (1) Los pasos para generar objetos se vuelven complicados (en realidad, la operación es relativamente simple), y para las personas que no están acostumbradas a este método, les resultará un poco incómodo y poco intuitivo. (2) La generación de objetos utiliza programación reflexiva, que tiene una cierta pérdida de eficiencia. Pero en comparación con el mantenimiento y la flexibilidad mejorados por IoC, esta pérdida es insignificante, a menos que los requisitos de eficiencia para generar un objeto sean particularmente altos. (3) Falta de soporte para operaciones de refactorización de IDE. Si desea cambiar el nombre de una clase en Eclipse, debe ir al archivo XML y cambiarlo manualmente. Esto parece faltar en todos los métodos XML.
Introducción a la implementación de IOC
IOC se ocupa de cómo se definen los servicios (o componentes de aplicaciones) y cómo deben ubicarse en relación con otros servicios de los que dependen. Normalmente, la separación de definición y posicionamiento se logra a través de un contenedor o marco de posicionamiento, que es responsable de:
Guardar una colección de servicios disponibles
Prever la vinculación de varios componentes a ellos Métodos de servicios dependientes
Proporcionar métodos para que el código de la aplicación solicite objetos de configuración (por ejemplo, objetos que satisfagan todas las dependencias). Este enfoque garantiza que todos los servicios relevantes requeridos por el objeto estén disponibles.
Los marcos existentes en realidad utilizan tres marcos técnicos básicos para realizar la vinculación entre servicios y componentes:
Tipo 1 (basado en interfaz): los objetos que pueden proporcionar servicios necesitan implementar una interfaz especializada que proporcione un objeto desde el cual se pueden encontrar dependencias (otros servicios). Uno de los primeros contenedores, Excalibur, utilizó este patrón.
Tipo 2 (basado en setter): especificación de servicios para objetos reparables a través de propiedades JavaBean (métodos setter). HiveMind y Spring utilizan este enfoque.
Tipo 3 (basado en constructor): especificar servicios para objetos reparables a través de parámetros de constructor. Esta es la única forma en que PicoContainer lo usa, y también lo usan HiveMind y Spring.