JAVA设计模式第七讲：设计模式在 Spring 源码中的应用-Toy模板网

这篇具有很好参考价值的文章主要介绍了JAVA设计模式第七讲：设计模式在 Spring 源码中的应用。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

设计模式（design pattern）是对软件设计中普遍存在的各种问题，所提出的解决方案。本文以面试题作为切入点，介绍了设计模式的常见问题。我们需要掌握各种设计模式的原理、实现、设计意图和应用场景，搞清楚能解决什么问题。本文是第七篇：设计模式在 Spring 源码中的应用

1、Spring 框架中蕴含的经典设计思想或原则

1、约定大于配置
- 基于注解的配置方式，我们在指定类上使用指定的注解，来替代集中的 XML 配置
  - 使用@RequestMapping注解，在controller类或接口上，标注对应的URL，使用 @Transaction注解表明支持事务等
- 基于约定的配置方式
  - 就是提供配置的默认值，优先使用默认值
  - 比如在 Spring JPA中，我们约定类名默认跟表名相同，属性名默认跟表字段名相同，String 类型对应数据库中的 varchar 类型，long 类型对应数据库中的 bigint 类型
  - 该方式很好地体现了“二八法则”
  - Gson也符合约定优于配置
2、低侵入、松耦合
- 框架代码很少耦合在业务代码中；
- Spring 提供的 IOC 容器，在不需要 Bean 继承任何父类或者实现任何接口的情况下，仅仅通过配置，就能将它们纳入进 Spring 的管理中。如果我们换一个 IOC 容器，也只是重新配置一下就可以了，原有的 Bean 都不需要任何修改；
- 基于 AOP 这种开发模式，将非业务代码集中放到切面中，删除、修改的成本就变得很低
3、模块化、轻量级
- 从下图我们可以看出，Spring 在分层、模块化方面做得非常好。每个模块都只负责一个相对独立的功能。模块之间关系，仅有上层对下层的依赖关系，而同层之间以及下层对上层，几乎没有依赖和耦合；
- 在依赖 Spring 的项目中，开发者可以有选择地引入某几个模块，而不会因为需要一个小的功能，就被强迫引入整个 Spring 框架；
4、再封装、再抽象
- Spring 对市面上主流的中间件、系统的访问类库，做了进一步的封装和抽象，提供了更高层次、更统一的访问接口；
- 比如，Spring 提供了 spring-data-redis 模块，对 Redis Java 开发类库做了进一步的封装，Spring Cache，它定义了统一、抽象的 Cache 访问接口，这些接口不依赖具体的 Cache 实现（Redis、Guava Cache、Caffeine 等）
  - 可以参考这两篇文章：SpringBoot第41讲：SpringBoot集成Redis - 基于RedisTemplate+Jedis的数据操作
  - SpringBoot第40讲：SpringBoot整合Caffeine cache(最优秀的本地缓存)

2、剖析Spring框架中用来支持扩展的两种设计模式

常用来实现扩展特性的设计模式有：观察者模式、模板模式、职责链模式、策略模式等。我们剖析 Spring 框架为了支持可扩展特性用的两种设计模式：观察者模式和模板模式

2.1、观察者模式在 Spring 中的应用

观察者模式是一种对象行为型模式。它表示的是一种对象与对象之间具有依赖关系，当一个对象发生改变的时候，这个对象所依赖的对象也会做出反应。Spring 事件驱动模型就是观察者模式很经典的一个应用。Spring 事件驱动模型非常有用，在很多场景都可以解耦我们的代码。比如我们每次添加商品的时候都需要重新更新商品索引，这个时候就可以利用观察者模式来解决这个问题。

观察者模式可以参考这篇文章：JAVA设计模式第四讲：行为型设计模式

第10.1节

Spring 事件驱动模型中的三种角色

事件角色

ApplicationEvent (org.springframework.context包下)充当事件的角色,这是一个抽象类，它继承了java.util.EventObject并实现了 java.io.Serializable接口。

Spring 中默认存在以下事件，他们都是对 ApplicationContextEvent 抽象类的实现(继承自ApplicationContextEvent)：

ContextStartedEvent：ApplicationContext 启动后触发的事件;
ContextStoppedEvent：ApplicationContext 停止后触发的事件;
ContextRefreshedEvent：ApplicationContext 初始化或刷新完成后触发的事件;
ContextClosedEvent：ApplicationContext 关闭后触发的事件。

继承类图如下：

事件监听者角色
ApplicationListener 充当了事件监听者角色，它是一个接口，里面只定义了一个 onApplicationEven()方法来处理ApplicationEvent。ApplicationListener接口类源码如下，可以看出接口定义，接口中的事件只要实现了 ApplicationEvent就可以了。所以，在 Spring中我们只要实现 ApplicationListener 接口的 onApplicationEvent() 方法即可完成监听事件

@FunctionalInterface
public interface ApplicationListener<E extends ApplicationEvent> extends EventListener {
    void onApplicationEvent(E var1);
}

ApplicationEvent 和 ApplicationListener 的代码实现都非常简单，内部并不包含太多属性和方法，它们最大的作用是做类型标识之用

public abstract class ApplicationEvent extends EventObject {
    /** use serialVersionUID from Spring 1.2 for interoperability */
    private static final long serialVersionUID = 7099057708183571937L;

    /** System time when the event happened */
    private final long timestamp;
    
  	public ApplicationEvent(Object source) {
      	super(source);
      	this.timestamp = System.currentTimeMillis();
    }
    
  	public final long getTimestamp() {
      	return this.timestamp;
    }
}

public class EventObject implements java.io.Serializable {
		protected transient Object source;
    public EventObject(Object source) {
        if (source == null)
          	throw new IllegalArgumentException("null source");
        this.source = source;
    }
    public Object getSource() {
      	return source;
    }
    public String toString() {
      	return getClass().getName() + "[source=" + source + "]";
    }
}

事件发布者角色
ApplicationEventPublisher 充当了事件的发布者，它也是一个接口。

@FunctionalInterface
public interface ApplicationEventPublisher {
    default void publishEvent(ApplicationEvent event) {
        this.publishEvent((Object)event);
    }
    void publishEvent(Object var1);
}

ApplicationEventPublisher 接口的publishEvent（）这个方法在AbstractApplicationContext 类中被实现，阅读这个方法的实现，你会发现实际上事件真正是通过 ApplicationEventMulticaster 来广播出去的。

Spring 的事件流程总结

定义一个事件: 实现一个继承自 ApplicationEvent，并且写相应的构造函数；
定义一个事件监听者：实现 ApplicationListener 接口，重写 onApplicationEvent() 方法；
使用事件发布者发布消息: 可以通过 ApplicationEventPublisher 的 publishEvent()方法发布消息。

// 定义一个事件，继承自ApplicationEvent并且写相应的构造函数
public class DemoEvent extends ApplicationEvent{
    private static final long serialVersionUID = 1L;
    private String message;
    public DemoEvent(Object source,String message){
        super(source);
        this.message = message;
    }
    public String getMessage() {
         return message;
    }
}

// 定义一个事件监听者，实现ApplicationListener接口，重写 onApplicationEvent() 方法；
@Component
public class DemoListener implements ApplicationListener<DemoEvent>{

    //使用onApplicationEvent接收消息
    @Override
    public void onApplicationEvent(DemoEvent event) {
        String msg = event.getMessage();
        System.out.println("接收到的信息是："+msg);
    }
}

// 发布事件，可以通过ApplicationEventPublisher 的 publishEvent() 方法发布消息。
@Component
public class DemoPublisher {
    @Autowired
    ApplicationContext applicationContext;

    public void publish(String message){
        //发布事件
        applicationContext.publishEvent(new DemoEvent(this, message));
    }
}

当调用 DemoPublisher 的 publish() 方法的时候，比如 demoPublisher.publish(“你好”) ，控制台就会打印出：接收到的信息是：你好。

其中，ApplicationContext 可以类比 Google EventBus 框架中的“事件总线”

ApplicationContext 这个类并不只是为观察者模式服务的。它底层依赖 BeanFactory（IOC 的主要实现类），提供应用启动、运行时的上下文信息，是访问这些信息的最顶层接口

ApplicationContext 只是一个接口，具体的代码实现包含在它的实现类AbstractApplicationContext 中。跟观察者模式相关的代码，如下所示。只需要关注它是如何发送事件和注册监听者就好

public abstract class AbstractApplicationContext extends DefaultResourceLoader implements ConfigurableApplicationContext {
    /** Statically specified listeners */
    private final Set<ApplicationListener<?>> applicationListeners = new LinkedHashSet<>();
    public Collection<ApplicationListener<?>> getApplicationListeners() {
        return this.applicationListeners;
    }

    @Override
    public void publishEvent(ApplicationEvent event) {
        publishEvent(event, null);
    }		

    @Override
    public void publishEvent(Object event) {
        publishEvent(event, null);
    }

    protected void publishEvent(Object event, @Nullable ResolvableType eventType) {	
        // Decorate event as an ApplicationEvent if necessary
        ApplicationEvent applicationEvent;
        if (event instanceof ApplicationEvent) {
            applicationEvent = (ApplicationEvent) event;
        }	
      	else {
            applicationEvent = new PayloadApplicationEvent<>(this, event);
            if (eventType == null) {
                eventType = ((PayloadApplicationEvent) applicationEvent).getResolvableType();
            }
        }

        // Multicast right now if possible - or lazily once the multicaster is initialized
        if (this.earlyApplicationEvents != null) {
            this.earlyApplicationEvents.add(applicationEvent);
        } 
      	else {
            getApplicationEventMulticaster().multicastEvent(applicationEvent, eventType);
        }

        // Publish event via parent context as well...
        if (this.parent != null) {
            if (this.parent instanceof AbstractApplicationContext) {
                ((AbstractApplicationContext) this.parent).publishEvent(event, eventType);
            } else {
                this.parent.publishEvent(event);
            }
        }
    }

    @Override
    public void addApplicationListener(ApplicationListener<?> listener) {
        Assert.notNull(listener, "ApplicationListener must not be null");
        if (this.applicationEventMulticaster != null) {
          	this.applicationEventMulticaster.addApplicationListener(listener);
        }
        else {
          	this.applicationListeners.add(listener);
        }
    }

    protected void registerListeners() {
        // Register statically specified listeners first.
        for (ApplicationListener<?> listener : getApplicationListeners()) {
            getApplicationEventMulticaster().addApplicationListener(listener);
        }

        // Do not initialize FactoryBeans here: We need to leave all regular beans
        // uninitialized to let post-processors apply to them!
        String[] listenerBeanNames = getBeanNamesForType(ApplicationListener.class, true, false);
        for (String listenerBeanName : listenerBeanNames) {
            getApplicationEventMulticaster().addApplicationListenerBean(listenerBeanName);
        }

        // Publish early application events now that we finally have a multicaster...
        Set<ApplicationEvent> earlyEventsToProcess = this.earlyApplicationEvents;
        this.earlyApplicationEvents = null;
        if (earlyEventsToProcess != null) {
            for (ApplicationEvent earlyEvent : earlyEventsToProcess) {
                getApplicationEventMulticaster().multicastEvent(earlyEvent);
            }
        }
    }
}

从代码中可以得出，真正的消息发送，实际上是通过 ApplicationEventMulticaster 这个类来完成的，它通过线程池，支持异步非阻塞、同步阻塞这两种类型的观察者模式。

public void multicastEvent(final ApplicationEvent event, @Nullable ResolvableType eventType) {
    ResolvableType type = (eventType != null ? eventType : resolveDefaultEventType(event));
    for (final ApplicationListener<?> listener : getApplicationListeners(event, type)) {
        Executor executor = getTaskExecutor();
        if (executor != null) {
          	executor.execute(() -> invokeListener(listener, event));
        }
        else {
          	invokeListener(listener, event);
        }
    }
}

结论：这也体现了 Spring 框架的扩展性，也就是在不需要修改任何代码的情况下，扩展新的事件和监听。

Action1：Google Guava 的 EventBus 实现中，被观察者发送消息到事件总线，事件总线根据消息的类型，将消息发送给可匹配的观察者。那在 Spring 提供的观察者模式的实现中，是否也支持按照消息类型匹配观察者呢？

支持按照消息类型匹配观察者，最终调用 SimpleApplicationEventMulticaster 类的multicastEvent方法通过反射匹配类型，根据配置采用异步还是同步的监听方式。

2.2、模板模式在 Spring 中的应用

模板模式是一种行为设计模式，它定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤的实现方式

模版模式可以参考这篇文章：JAVA设计模式第四讲：行为型设计模式

第10.1节

与之相关的面试题：请你说下 Spring Bean 的创建过程包含哪些主要的步骤？

Spring Bean 的创建过程，可以大致分为两大步：对象的创建和对象的初始化

其中就涉及模板模式。它也体现了 Spring 的扩展性。利用模板模式，Spring 能让用户定制 Bean 的创建过程

对象的初始化有两种实现方式。一种是在类中自定义一个初始化函数，并且通过配置文件，显式地告知 Spring，哪个函数是初始化函数。如下所示，在配置文件中，我们通过 init-method 属性来指定初始化函数。

public class DemoClass {
    //...
    public void initDemo() {
      //...初始化..
    }
}
// 配置：需要通过init-method显式地指定初始化方法
<bean id="demoBean" class="com.xzg.cd.DemoClass" init-method="initDemo"></bean>

缺点：这种初始化函数并不固定，由用户随意定义

解决方案：Spring 提供了另外一个定义初始化函数的方法，那就是让类实现Initializingbean 接口。这个接口包含一个固定的初始化函数定义（afterPropertiesSet() 函数）。Spring 在初始化 Bean 的时候，可以直接通过 bean.afterPropertiesSet() 的方式，调用 Bean 对象上的这个函数，而不需要使用反射来调用了。

代码示例如下：

public class DemoClass implements InitializingBean {
    @Override
    public void afterPropertiesSet() throws Exception {
      //...初始化...
    }
}
// 配置：不需要显式地指定初始化方法
<bean id="demoBean" class="com.xzg.cd.DemoClass"></bean>

这种方法的缺点：业务代码（DemoClass）跟框架代码（InitializingBean）耦合在了一起，替换框架的成本就变高了。

Bean 的销毁过程，在 Java 中，对象的回收是通过 JVM 来自动完成的。但是，我们可以在将 Bean 正式交给 JVM 垃圾回收前，执行一些销毁操作。

两种实现方式

1、通过配置 destroy-method 指定类中的销毁函数
2、实现 DisposableBean 接口

Spring Bean 的整个生命周期如下图所示，它将要执行的函数封装成对象，传递给模板（BeanFactory）来执行。

对象的初始化又可以分解为 3 个小的步骤：初始化前置操作、初始化、初始化后置操作。
- 定义在接口 BeanPostProcessor 中

Spring 中的 ApplicationContext 会自动检测在配置文件中实现了 BeanPostProcessor 接口的所有 Bean，并把它们注册到 BeanPostProcessor 处理器列表中。在 Spring 容器创建 Bean 的过程中，Spring 会逐一去调用这些处理器。

public interface BeanPostProcessor {
		Object postProcessBeforeInitialization(Object var1, String var2) throws BeansException;
		Object postProcessAfterInitialization(Object var1, String var2) throws BeansException;
}

Spring 中 jdbcTemplate、hibernateTemplate 等以 Template 结尾的对数据库操作的类，它们就使用到了模板模式。一般情况下，我们都是使用继承的方式来实现模板模式，但是 Spring 并没有使用这种方式，而是使用Callback 模式与模板方法模式配合，既达到了代码复用的效果，同时增加了灵活性。

Action：模板方法的样例代码如下所示

public abstract class Template {
    //这是我们的模板方法
    public final void TemplateMethod(){
        PrimitiveOperation1();  
        PrimitiveOperation2();
        PrimitiveOperation3();
    }
    protected void  PrimitiveOperation1(){
        //当前类实现
    }

    //被子类实现的方法
    protected abstract void PrimitiveOperation2();
    protected abstract void PrimitiveOperation3();

}
public class TemplateImpl extends Template {
    @Override
    public void PrimitiveOperation2() {
        //当前类实现
    }
    @Override
    public void PrimitiveOperation3() {
        //当前类实现
    }
}

Action1：请你说下 Spring Bean 的创建过程包含哪些主要的步骤？

3、总结Spring框架用到的11种设计模式

3.1、适配器模式在 Spring 中的应用

在 Spring MVC 中，定义一个 Controller 最常用的方式是，通过 @Controller 注解来标记某个类是 Controller 类，通过@RequesMapping 注解来标记函数对应的 URL。

定义一个 Controller的三种方法

方法一：通过 @Controller、@RequestMapping 来定义

@Controller
public class DemoController {
    
  	@RequestMapping("/employname")
    public ModelAndView getEmployeeName() {
        ModelAndView model = new ModelAndView("Greeting");
        model.addObject("message", "Dinesh");
        return model;
    }
}

方法二：实现Controller接口 + xml配置文件：配置 DemoController 与URL的对应关系

public class DemoController implements Controller {
    
  	@Override
    public ModelAndView handleRequest(HttpServletRequest req, HttpServletResponse resp) {
        ModelAndView model = new ModelAndView("Greeting");
        model.addObject("message", "Dinesh Madhwal");
        return model;
    }
}

方法三：实现Servlet接口 + xml配置文件：配置 DemoController 类与URL的对应关系

public class DemoServlet extends HttpServlet {
    
  	@Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws  Exception {
      	this.doPost(req, resp);
    } 
    
  	@Override
    protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws Exception {
      	resp.getWriter().write("Hello World.");
    }
}

在应用启动的时候，Spring 容器会加载这些 Controller 类，并且解析出 URL 对应的处理函数，封装成 Handler 对象，存储到 HandlerMapping 对象中。当有请求到来的候，DispatcherServlet 从 HanderMapping 中，查找请求 URL 对应的 Handler，然后调用执行 Handler 对应的函数代码，最后将执行结果返回给客户端。

3.2、策略模式在Spring 中的应用

Todo

3.3、组合模式在 Spring 中的应用

Todo

3.4、装饰器模式在 Spring 中的应用

装饰者模式可以动态地给对象添加一些额外的属性或行为。相比于使用继承，装饰者模式更加灵活。简单点儿说就是当我们需要修改原有的功能，但我们又不愿直接去修改原有的代码时，设计一个Decorator套在原有代码外面。其实在 JDK 中就有很多地方用到了装饰者模式，比如 InputStream家族，InputStream 类下有 FileInputStream (读取文件)、BufferedInputStream (增加缓存,使读取文件速度大大提升)等子类都在不修改InputStream 代码的情况下扩展了它的功能。

JAVA设计模式第七讲：设计模式在 Spring 源码中的应用,Java 设计模式详解,java,设计模式,spring,源码分析,约定大于配置,模块化,高拓展性

装饰者模式示意图

Spring 中配置 DataSource 的时候，DataSource 可能是不同的数据库和数据源。我们能否根据客户的需求在少修改原有类的代码下动态切换不同的数据源？这个时候就要用到装饰者模式。Spring 中用到的包装器模式在类名上含有 Wrapper或者 Decorator。这些类基本上都是动态地给一个对象添加一些额外的职责。

3.5、工厂模式在 Spring 中的应用

Spring使用工厂模式可以通过 BeanFactory 或 ApplicationContext 创建 bean 对象。

两者对比：

BeanFactory：延迟注入(使用到某个 bean 的时候才会注入)，相比于ApplicationContext 来说会占用更少的内存，程序启动速度更快。
ApplicationContext：容器启动的时候，不管你用没用到，一次性创建所有 bean。BeanFactory 仅提供了最基本的依赖注入支持， ApplicationContext 扩展了 BeanFactory，除了有BeanFactory的功能还有额外更多功能，所以一般开发人员使用ApplicationContext 会更多。

ApplicationContext 的三个实现类：

ClassPathXmlApplication：把上下文文件当成类路径资源。
FileSystemXmlApplication：从文件系统中的 XML 文件载入上下文定义信息。
XmlWebApplicationContext：从Web系统中的XML文件载入上下文定义信息。

import org.springframework.context.ApplicationContext;
import org.springframework.context.support.FileSystemXmlApplicationContext;

public class App {
    public static void main(String[] args) {
        ApplicationContext context = new FileSystemXmlApplicationContext(
                "C:/work/IOC Containers/springframework.applicationcontext/src/main/resources/bean-factory-config.xml");
        HelloApplicationContext obj = (HelloApplicationContext) context.getBean("helloApplicationContext");
        obj.getMsg();
    }
}

3.6、代理模式在 Spring 中的应用

Spring中两种代理方式，
1、若目标对象实现了若干接口，spring使用JDK的java.lang.reflect.proxy类代理，
2、若目标对象没有实现任何接口，spring使用CGLIB库生成目标对象的子类。
代理模式经典应用是 AOP

3.7、单例模式在 Spring 中的应用

在我们的系统中，有一些对象其实我们只需要一个，比如说：线程池、缓存、对话框、注册表、日志对象、充当打印机、显卡等设备驱动程序的对象。事实上，这一类对象只能有一个实例，如果制造出多个实例就可能会导致一些问题的产生，比如：程序的行为异常、资源使用过量、或者不一致性的结果。

使用单例模式的好处:

对于频繁使用的对象，可以省略创建对象所花费的时间，这对于那些重量级对象而言，是非常可观的一笔系统开销；
由于 new 操作的次数减少，因而对系统内存的使用频率也会降低，这将减轻 GC 压力，缩短 GC 停顿时间。

Spring 中 bean 的默认作用域就是 singleton(单例)的。除了 singleton 作用域，Spring 中 bean 还有下面几种作用域：

prototype : 每次请求都会创建一个新的 bean 实例。
request : 每一次HTTP请求都会产生一个新的bean，该bean仅在当前HTTP request内有效。
session : 每一次HTTP请求都会产生一个新的 bean，该bean仅在当前 HTTP session 内有效。
global-session：全局session作用域，仅仅在基于portlet的web应用中才有意义，Spring5已经没有了。Portlet是能够生成语义代码(例如：HTML)片段的小型Java Web插件。它们基于portlet容器，可以像servlet一样处理HTTP请求。但是，与 servlet 不同，每个 portlet 都有不同的会话

Spring 实现单例的方式：

xml : <bean id="userService" class="top.snailclimb.UserService" scope="singleton"/>

注解：@Scope(value = “singleton”)

Spring 通过 ConcurrentHashMap 实现单例注册表的特殊方式实现单例模式。Spring 实现单例的核心代码如下

// 通过 ConcurrentHashMap（线程安全） 实现单例注册表
private final Map<String, Object> singletonObjects = new ConcurrentHashMap<String, Object>(64);

public Object getSingleton(String beanName, ObjectFactory<?> singletonFactory) {
        Assert.notNull(beanName, "'beanName' must not be null");
        synchronized (this.singletonObjects) {
            // 检查缓存中是否存在实例  
            Object singletonObject = this.singletonObjects.get(beanName);
            if (singletonObject == null) {
                //...省略了很多代码
                try {
                    singletonObject = singletonFactory.getObject();
                }
                //...省略了很多代码
                // 如果实例对象在不存在，我们注册到单例注册表中。
                addSingleton(beanName, singletonObject);
            }
            return (singletonObject != NULL_OBJECT ? singletonObject : null);
        }
    }
    //将对象添加到单例注册表
    protected void addSingleton(String beanName, Object singletonObject) {
            synchronized (this.singletonObjects) {
                this.singletonObjects.put(beanName, (singletonObject != null ? singletonObject : NULL_OBJECT));
            }
   }
}

3.8、Spring MVC中的适配器模式

在Spring MVC中，DispatcherServlet 根据请求信息调用 HandlerMapping，解析请求对应的 Handler。解析到对应的 Handler（也就是我们平常说的 Controller 控制器）后，开始由HandlerAdapter 适配器处理。HandlerAdapter 作为期望接口，具体的适配器实现类用于对目标类进行适配，Controller 作为需要适配的类。

为什么要在 Spring MVC 中使用适配器模式？

Spring MVC 中的 Controller 种类众多，不同类型的 Controller 通过不同的方法来对请求进行处理。如果不利用适配器模式的话，DispatcherServlet 直接获取对应类型的 Controller，需要的自行来判断，像下面这段代码一样：

if(mappedHandler.getHandler() instanceof MultiActionController){  
   ((MultiActionController)mappedHandler.getHandler()).xxx  
}else if(mappedHandler.getHandler() instanceof XXX){  
    ...  
}else if(...){  
   ...  
}

假如我们再增加一个 Controller类型就要在上面代码中再加入一行判断语句，这种形式就使得程序难以维护，也违反了设计模式中的开闭原则 – 对扩展开放，对修改关闭。

3.9、职责链模式在 Spring 中的应用

拦截器
职责链模式在 Spring 中的应用是拦截器（Interceptor）

4、总结

Spring 框架中用到了哪些设计模式？文章来源地址https://www.toymoban.com/news/detail-704591.html

工厂设计模式 : Spring使用工厂模式通过 BeanFactory、ApplicationContext 创建 bean 对象。
代理设计模式 : Spring AOP 功能的实现。
单例设计模式 : Spring 中的 Bean 默认都是单例的。
模板方法模式 : Spring 中 jdbcTemplate、hibernateTemplate 等以 Template 结尾的对数据库操作的类，它们就使用到了模板模式。
包装器设计模式 : 我们的项目需要连接多个数据库，而且不同的客户在每次访问中根据需要会去访问不同的数据库。这种模式让我们可以根据客户的需求能够动态切换不同的数据源。
观察者模式: Spring 事件驱动模型就是观察者模式很经典的一个应用。
适配器模式 :Spring AOP 的增强或通知(Advice)使用到了适配器模式、spring MVC 中也是用到了适配器模式适配Controller。

到了这里，关于JAVA设计模式第七讲：设计模式在 Spring 源码中的应用的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！