¿Qué patrones de diseño utiliza principalmente Spring? ¿Cómo se implementa el patrón singleton?
Los patrones de diseño son un libro de almohadas en el trabajo y el estudio, pero muchas veces nos encontramos en la incómoda posición de decir que no son necesarios. No es que los olvidemos todo el tiempo, es solo que los olvidamos. nunca los recuerdes.
Hoy, Crab analiza el valor intrínseco de los patrones de diseño en el sitio web de IT Learner y utiliza Spring como ejemplo para explicarlo. Sólo comprendiendo sus ideas de diseño podemos aplicarlas en el trabajo y el estudio. .
Como marco clásico en la industria, Spring es un modelo en la industria tanto en términos de diseño de arquitectura como de escritura de código. Bien, sin más preámbulos, comencemos el contenido de hoy.
Hay nueve patrones de diseño comúnmente utilizados en primavera. Pongamos ejemplos:
El primero: fábrica simple
También llamado método de fábrica estática (Método StaticFactory). patrón, pero no pertenece a uno de los 23 patrones de diseño GOF. ?
La esencia del patrón de fábrica simple es que una clase de fábrica determina dinámicamente qué clase de producto debe crearse en función de los parámetros entrantes. ?
BeanFactory en primavera es la encarnación del patrón de fábrica simple. El objeto bean se obtiene pasando un identificador único, pero depende si se crea después de pasar los parámetros o antes de pasarlos. de la situación específica. Depende de la situación. La siguiente configuración crea un itxxzBean en la clase HelloItxxz.
singleton="false">
Segundo: Fábrica Método
Por lo general, la aplicación utiliza directamente new para crear un nuevo objeto. Para separar la creación y el uso del objeto, se adopta el patrón de fábrica, es decir, la aplicación transfiere las responsabilidades de creación e inicialización. del objeto.
Generalmente, la aplicación tiene su propio objeto de fábrica para crear beans. Si el propio objeto de fábrica de la aplicación se entrega a Spring para su administración, Spring no administrará beans ordinarios, sino beans de fábrica.
Crab utilizará el método estático en el método de fábrica como ejemplo para explicar:
import java.util.Random;
public class StaticFactoryBean {
Entero estático público createRandom() {
return new Integer(new Random().nextInt());
}
}
Cree un archivo de configuración config.xm e incorpórelo al contenedor Spring para su administración. Debe especificar el nombre del método estático a través del método de fábrica
class="example.chapter3.StaticFactoryBean" factory-method="createRandom" //El método createRandom debe ser estático para encontrar el alcance="prototype" /> Prueba: public static void main(String[] args) { //Al llamar a getBean(), se devuelve un número aleatorio si no se utiliza el método de fábrica. especificado, se devolverá una instancia de StaticFactoryBean. Es decir, ¿devolverá una instancia del Bean de fábrica? ).toString()); } El tercer tipo: modo Singleton (. Singleton) Asegúrese de que una clase tenga solo una instancia y proporcione un acceso a su punto de acceso global. ? El modo singleton en primavera completa la segunda mitad de la oración, es decir, proporciona el punto de acceso global BeanFactory. Pero no existe un control singleton desde el nivel del constructor, porque Spring administra objetos Java arbitrarios. ? Consejo principal: los beans predeterminados en Spring son todos singleton, que se pueden especificar mediante singleton="true|false" o alcance="?" El cuarto tipo: adaptador (Adaptador) En Spring's Aop, Advice (consejo) se utiliza para mejorar la funcionalidad de la clase proxy. El principio de la implementación de Spring de esta función AOP es utilizar el modo proxy (1. proxy dinámico JDK. 2. proxy de tecnología de generación de código de bytes CGLib) para mejorar los aspectos a nivel de método de la clase, es decir, generar la clase proxy de la clase proxy, y Establecer un interceptor antes del método de la clase proxy, y mejorar la función del método proxy ejecutando el contenido importante del interceptor, realizando programación orientada a aspectos. Interfaz de clase de adaptador: Target interfaz pública AdvisorAdapter { boolean supportAdvice(Consejo de asesoramiento); MethodInterceptor getInterceptor(Asesor de asesor) ; } Clase MethodBeforeAdviceAdapter, Adaptador clase MethodBeforeAdviceAdapter implementa AdvisorAdapter, Serializable { supportsAdvice booleano público (consejos) { return (instancia de asesoramiento de MethodBeforeAdvice); } public MethodInterceptor getInterceptor(Asesor de Advisor) { Consejo de MethodBeforeAdvice = (MethodBeforeAdvice) asesor.getAdvice(); p> devuelve nuevo MethodBeforeAdviceInterceptor(advice); } } El quinto tipo: contenedor (Decorator) Nos encontramos con un problema de este tipo en nuestro proyecto: nuestro proyecto necesita conectarse a múltiples bases de datos, y diferentes clientes accederán a diferentes bases de datos según sus necesidades durante cada visita. En el pasado, siempre configurábamos una fuente de datos en los marcos de primavera e hibernación, por lo que el atributo dataSource de sessionFactory siempre apuntaba a esta fuente de datos y permanecía constante. Todos los DAO acceden a la base de datos a través de esta fuente de datos cuando usaban sessionFactory. Pero ahora, debido a las necesidades del proyecto, nuestro DAO tiene que cambiar constantemente entre múltiples fuentes de datos al acceder a sessionFactory. Surge la pregunta: cómo hacer que sessionFactory cambie dinámicamente según las necesidades del cliente al realizar la persistencia de datos. fuentes de datos? ¿Podemos resolverlo con algunas modificaciones bajo el marco de primavera? ¿Existe algún patrón de diseño que pueda utilizarse? ? Primero piense en configurar todas las fuentes de datos en el contexto de aplicación de Spring. Estas fuentes de datos pueden ser de varios tipos, como diferentes bases de datos: Oracle, SQL Server, MySQL, etc., o pueden ser diferentes fuentes de datos: como org.apache.commons.dbcp.BasicDataSource proporcionada por Apache u org proporcionada por primavera.jndi.JndiObjectFactoryBean, etc. Luego, sessionFactory establece el atributo dataSource en una fuente de datos diferente de acuerdo con la solicitud de cada cliente para lograr el propósito de cambiar las fuentes de datos. El patrón contenedor utilizado en Spring tiene dos manifestaciones en el nombre de la clase: una es que el nombre de la clase contiene Wrapper y la otra es que el nombre de la clase contiene Decorator. Básicamente, agregan dinámicamente algunas responsabilidades adicionales a un objeto. ? Categoría 6: Proxy Proporciona un proxy para que otros objetos controlen el acceso a este objeto. Estructuralmente, es similar al modo Decorador, pero Proxy es control, más como una restricción de funciones, mientras que Decorador es para aumentar las responsabilidades. ? El modo Proxy de Spring se refleja en aop, como JdkDynamicAopProxy y Cglib2AopProxy. ? Séptimo tipo: Observador Define una relación de dependencia de uno a muchos entre objetos. Cuando el estado de un objeto cambia, todos los objetos que dependen de él son notificados y actualizados. automáticamente. El lugar más utilizado para el patrón Observer en primavera es la implementación del oyente. Como ApplicationListener. ? Octavo: Estrategia Definir una serie de algoritmos, encapsularlos uno por uno y hacerlos intercambiables. Este patrón permite que el algoritmo cambie independientemente del cliente que lo utilice. ? El modo de estrategia se utiliza al crear instancias de objetos en primavera En SimpleInstantiationStrategy, el siguiente código ilustra el uso del modo de estrategia: ? Capítulo nueve: Método de plantilla Definir el esqueleto de un algoritmo en funcionamiento y diferir algunos pasos a subclases. El método de plantilla permite a las subclases redefinir ciertos pasos específicos de un algoritmo sin cambiar la estructura del algoritmo. El patrón del método de plantilla generalmente debe heredarse. Aquí quiero explorar otra comprensión del método de plantilla. Cuando usamos JdbcTemplate en primavera, no queremos heredar esta clase porque tiene demasiados métodos, pero aún queremos usar la conexión de base de datos pública y estable que tiene JdbcTemplate. Entonces, ¿qué debemos hacer? Podemos extraer los cambios y pasarlos al método JdbcTemplate como parámetro. Pero lo que cambia es un fragmento de código, y este código utilizará variables en JdbcTemplate. ¿Qué hacer? Entonces usemos objetos de devolución de llamada. Defina un método en este objeto de devolución de llamada para manipular las variables en JdbcTemplate. Cuando implementemos este método, concentraremos los cambios aquí. Luego pasamos este objeto de devolución de llamada a JdbcTemplate para completar la llamada. Esta puede ser otra forma de implementar el método de plantilla sin herencia.