设计模式学习笔记 - 开源实战四（中）：剖析Spring框架中用来支持扩展的设计模式

概述

上篇文章，学习了 Spring 框架背后蕴含的设计思想，比如约定优于配置、低侵入松耦合、模块化轻量级等等。这些设计思想可以借鉴到其他框架开发中，在大的设计层面提高框架的代码质量。

除了上篇文章降到的设计思想，实际上，可扩展也是大部分框架应该具备的一个重要特性。所谓框架可扩展，就是框架使用中在不修改框架源码的情况下，基于扩展点定制扩展新的功能。

前面在理论部分，曾经讲过，常用来实现扩展特性的设计模式有：观察者模式、模板模式、职责链模式、策略模式等。本章，再剖析下 Spring 框架为了支持可扩展特性用的 2 种设计模式：观察者模式和模板模式。

---

观察者模式在 Spring 中的应用

前面章节讲过，Java、Google Guava 都提供了观察者模式的实现框架。Java 提供的框架比较简单，只包含 java.util.Observable 和 java.util.Observer 两个类。Google Guava 提供的框架功能比较完善和强大：通过 EventBus 事件总线来实现观察者模式。实际上，Spring 也提供了观察者模式的实现框架。

Spring 中实现的观察者模式包含三部分：Event 事件（相当于消息）、Listener 监听者（相当于观察者）、Publisher 发送者（相当于被观察者）。通过一个例子来看下，Spring 提供的观察者模式是怎么使用的。

public class DemoEvent extends ApplicationEvent {
    private String message;
    public DemoEvent(Object source, String message) {
        super(source);
        this.message = message;
    }

    public String getMessage() {
        return message;
    }
}

// Listener监听者
@Component
public class DemoListener implements ApplicationListener<DemoEvent> {
    @Override
    public void onApplicationEvent(DemoEvent demoEvent) {
        String message = demoEvent.getMessage();
        System.out.println(message);
    }
}

// Publisher发送者
@Component
public class DemoPublisher {
    @Autowired
    private ApplicationContext applicationContext;

    public void publishEvent(DemoEvent demoEvent) {
        this.applicationContext.publishEvent(demoEvent);
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

从代码中可以看出，框架使用起来并不复杂，主要包含三部分工作：定义一个继承 ApplicationEvent 的事件（DemoEvent）；定义了一个实现 ApplicationListener 的监听器（DemoListener）；定义了一个发送者（DemoPublisher），发送者调用 ApplicationContext 来发送事件消息。

其中，ApplicationEvent 和 ApplicationListener 的代码实现都非常简单，内部并不包含太多属性和方法。实际上，它们最大的作用就是做类型标识用（继承 ApplicationEvent 的类是事件，实现 ApplicationListener 的类是监听器）。

public abstract class ApplicationEvent extends EventObject {
    private static final long serialVersionUID = 7099057708183571937L;
    private final long timestamp = System.currentTimeMillis();

    public ApplicationEvent(Object source) {
        super(source);
    }

    public final long getTimestamp() {
        return this.timestamp;
    }
}

public class EventObject implements java.io.Serializable {
    private static final long serialVersionUID = 5516075349620653480L;
    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 + "]";
    }
}

@FunctionalInterface
public interface ApplicationListener<E extends ApplicationEvent> extends EventListener {
    void onApplicationEvent(E var1);
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

前面讲观察者模式时，我们提到，观察者需要实现注册到被观察者（JDK 的实现方式）或者事件总线（EventBus 的实现方式）中。那在 Spring 的实现中，观察者被注册到了哪里呢？是如何注册的呢？

Spring 的实现中，观察者被注册到了 ApplicationContext 对照中。这里的 ApplicationContext 就相当于 Google EventBus 框架中的 “事件总线”。不过稍微提醒一下，ApplicationContext 这个类并不是为观察者模式服务的。它底层依赖 BeanFactory （IOC 的主要实现类），提供应用启动、运行时的上下文信息，是访问你些信息的最顶层接口。

实际上，具体到源码来说，ApplicationContext 只是一个接口，具体的代码实现包含在它的实现类 AbstractApplicationContext 中。我们把观察者模式相关的代码，摘抄到了下面。你只需要关注它是如何发送事件和注册监听者就好，其他细节不需要深究。

public abstract class AbstractApplicationContext extends DefaultResourceLoader implements ConfigurableApplicationContext {
	// ...
	private final Set<ApplicationListener<?>> applicationListeners;
	// ...
	public void publishEvent(ApplicationEvent event) {
        this.publishEvent(event, (ResolvableType)null);
    }

    public void publishEvent(Object event) {
        this.publishEvent(event, (ResolvableType)null);
    }

    protected void publishEvent(Object event, @Nullable ResolvableType eventType) {
        Assert.notNull(event, "Event must not be null");
        Object applicationEvent;
        if (event instanceof ApplicationEvent) {
            applicationEvent = (ApplicationEvent)event;
        } else {
            applicationEvent = new PayloadApplicationEvent(this, event);
            if (eventType == null) {
                eventType = ((PayloadApplicationEvent)applicationEvent).getResolvableType();
            }
        }

        if (this.earlyApplicationEvents != null) {
            this.earlyApplicationEvents.add(applicationEvent);
        } else {
            this.getApplicationEventMulticaster().multicastEvent((ApplicationEvent)applicationEvent, eventType);
        }

        if (this.parent != null) {
            if (this.parent instanceof AbstractApplicationContext) {
                ((AbstractApplicationContext)this.parent).publishEvent(event, eventType);
            } else {
                this.parent.publishEvent(event);
            }
        }
    }
    
    // ...
    
    public void addApplicationListener(ApplicationListener<?> listener) {
        Assert.notNull(listener, "ApplicationListener must not be null");
        if (this.applicationEventMulticaster != null) {
            this.applicationEventMulticaster.addApplicationListener(listener);
        }
        this.applicationListeners.add(listener);
    }

    public Collection<ApplicationListener<?>> getApplicationListeners() {
        return this.applicationListeners;
    }
    
    // ...
    protected void registerListeners() {
        Iterator var1 = this.getApplicationListeners().iterator();

        while(var1.hasNext()) {
            ApplicationListener<?> listener = (ApplicationListener)var1.next();
            this.getApplicationEventMulticaster().addApplicationListener(listener);
        }

        String[] listenerBeanNames = this.getBeanNamesForType(ApplicationListener.class, true, false);
        String[] var7 = listenerBeanNames;
        int var3 = listenerBeanNames.length;

        for(int var4 = 0; var4 < var3; ++var4) {
            String listenerBeanName = var7[var4];
            this.getApplicationEventMulticaster().addApplicationListenerBean(listenerBeanName);
        }

        Set<ApplicationEvent> earlyEventsToProcess = this.earlyApplicationEvents;
        this.earlyApplicationEvents = null;
        if (earlyEventsToProcess != null) {
            Iterator var9 = earlyEventsToProcess.iterator();

            while(var9.hasNext()) {
                ApplicationEvent earlyEvent = (ApplicationEvent)var9.next();
                this.getApplicationEventMulticaster().multicastEvent(earlyEvent);
            }
        }

    }
    
    //...
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86

从上面的代码中，可以发现，真正的消息发送，实际上是通过 ApplicationEventMulticaster 这个类来完成的。这个类的源码也是只摘抄了最关键的一部分，也就是 multicastEvent() 这个消息发送函数。不过，它的代码并不复杂。它通过线程池，支持异步非阻塞、同步组赛两种类型的观察者模式。

public class SimpleApplicationEventMulticaster extends AbstractApplicationEventMulticaster {
	// ...
	public void multicastEvent(ApplicationEvent event) {
        this.multicastEvent(event, this.resolveDefaultEventType(event));
    }

    public void multicastEvent(ApplicationEvent event, @Nullable ResolvableType eventType) {
        ResolvableType type = eventType != null ? eventType : this.resolveDefaultEventType(event);
        Iterator var4 = this.getApplicationListeners(event, type).iterator();

        while(var4.hasNext()) {
            ApplicationListener<?> listener = (ApplicationListener)var4.next();
            Executor executor = this.getTaskExecutor();
            if (executor != null) {
                executor.execute(() -> {
                    this.invokeListener(listener, event);
                });
            } else {
                this.invokeListener(listener, event);
            }
        }
    }
    // ...
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

借助 Spring 提供的观察者模式的骨架代码，如果要在 Spring 下实现某个事件的发送和监听，只需要做很少的工作，定义事件、定义监听器、往 ApplicationContext 中发送事件就可以了，剩下的工作都由 Spring 框架来完成。实际上，这也体现了 Spring 框架的扩展性，也就是在不需要修改任何代码的情况下，扩展新的事件和监听器。

模板模式在 Spring 中的应用

刚刚讲的是观察者模式在 Spring 中的应用，现在再讲下模板模式。

有一个问题经常在面试中被问到：请你说一下 Spring Bean 的创建过程包含哪些主要的步骤。这其中就涉及模板模式。它也体现了 Spring 的扩展性。利用模板模式，Spring 能让用户定制 Bean 的创建过程。

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

对象的创建是通过反射来动态生成对象，而不是 new 方法。不管哪种方式，说白了，总归还是调用构造函数来生成对象。对象的初始化有两种实现方式。一种是在类中自定义一个初始化函数，并通过配置文件，显示地告知 Spring，哪个函数是初始化函数。下面是一个例子，在配置文件中，通过 init-method 属性来指定初始化函数。

public class DemoClass {
	// ...
	
	public void initDemo() {
		// 初始化...
	}
}

// 配置：需通过 init-method 显式地指定初始化方法
<bean id="demoBean" class="com.example.DemoClass" init-method="initDemo"></bean>
1
2
3
4
5
6
7
8
9
10

这种初始化方式有一个缺点，初始化函数并不固定，由用户随意定义，这就需要 Spring 通过反射，在运行时动态地调用这个初始化函数。而反射又会影响代码执行的性能，那有没有替代方案呢？

Spring 提供了另外一个定义初始化函数的方式，让类实现 InitializingBean 接口。这个接口包含一个固定的初始化函数的定义（afterPropertiesSet() 函数）。Spring 在初始化 Bean 时，可以直接通过 bean.afterPropertiesSet() 的方式，调用 Bean 对象上的这个函数，而不需要使用反射来调用了。例子代码如下所示：

public class DemoClass implements InitializingBean {
	@Override
	public void afterPropertiesSet() throw Exception {
		// 初始化...
	}
}

// 配置不需要显式的指定初始化方法
<bean id="demoBean" class="com.example.DemoClass"></bean>
1
2
3
4
5
6
7
8
9

尽管这种方式不会用到反射，执行效率提高了，但业务代码（DemoClass）跟框架代码（InitializingBean）耦合在了一起。框架代码侵入到了业务代码中，替换框架的成本就高了。所以，不是很推荐这种写法。

实际上，Spring 对 Bean 整个生命周期的管理中，还有一个跟初始化相对应的过程，那就是 Bean 的销毁过程。我们知道，Java 中对象的回收是通过 JVM 来自动完成的。但是，我们可以将 Bean 正式交给 JVM 垃圾回收前，执行一些销毁操作（比如关闭文件句柄等等）。

销毁过程跟初始化过程类似，也有两种实现方式。一种是通过配置 destory-method 指定类中的销毁函数，另一种是让实现类实现 DisposableBean 接口。因为 destory-method、 DisposableBean 跟 init-method、InitializingBean 非常相似，所以这部分就不详细讲解了。

实际上，Spring 针对对象的初始化过程，还进一步做了细化，将它拆分成了三个小步骤：初始化前置操作、初始化、初始化后置操作。其中，中间的初始化操作就是我们刚刚讲的那部分，初始化的前置和后置操作，定义在 BeanPostProcessor 中。BeanPostProcessor 的接口定义如下所示：

public interface BeanPostProcessor {
	@Nullable
	Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException;
	
	@Nullable
	Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException;
}

1
2
3
4
5
6
7
8

我们只需要定义一个实现了 BeanPostProcessor 接口的处理类，并在配置文件中像配置普通 Bean 一样去配置就可以了。Spring 中的 ApplicationContext 会自动检测配置文件中实现了 BeanPostProcessor 接口的所有 Bean，并把它们注册到 BeanPostProcessor 处理器列表中。在 Spring 容器创建 Bean 的过程中，Spring 会逐一去调用这些处理器。

通过上面的分析，基本上弄清楚了 Spring Bean 的整个生命周期（创建加销毁）。

不过，你可能会说，这哪里使用到了模板模式啊？模板模式不是定义一个包含模板方法的抽象类，以及定义子类实现模板方法吗？

实际上，这里的模板模式的实现，并不是标准的实现方式，而是有点类似 Callback 回调的实现方式，也就是将要执行的函数封装成对象（比如初始化方法封装成 InitializingBean 对象），传递给模板（BeanFactory）来执行。

总结

本章讲道理 Spring 中用到的两种支持扩展的设计模式：观察者模式和模板模式。

其中，观察者模式在 Java、Google Guava、Spring 中都有提供相应的实现代码。在平时的项目开发中，基于这些实现代码，我们可以轻松地实现一个观察者模式。

Java 提供的空间比较简单，只包含 java.util.Observable 和 java.util.Observer 两个类。Google Guava 提供的框架功能比较完成和强大，可以通过 EventBus 事件总线来实现观察者模式。Spring 提供了观察者模式包括 Event 事件、Listener 监听者、Publisher 发送者三部分。事件发送到 ApplicationContext 中，然后 ApplicationContext 将消息发送给实现注册好的监听者。

此外，还讲到模板模式在 Spring 中的一个典型应用，那就是 Bean 的创建过程。Bean 的创建包括两个大的步骤：对象的创建和对象的初始化。其中，对象的初始化可以分解为 3 个小的步骤：初始化前置操作、初始化、初始化后置操作。