参考文章：
面试必备：常用的设计模式总结
这篇文章中讲到了 单例模式、观察者模式、装饰器模式 和 适配器模式，以及最常见的三种工厂模式（简单工厂、工厂方法、抽象工厂），讲述较为生动并且附有代码，可以对应本文的第一到五节作为参考。
讲讲Spring中都用到了那些设计模式?
Spring中涉及的设计模式总结
问题引入
-
JDK 中涉及哪些设计模式？
参考：JDK中设计模式
可以了解 JDK 中使用了大量的设计模式，做到了解几种常见设计模式在 JDK 中的实现即可。 -
Spring 框架中用到了哪些设计模式？
- 单例模式：Bean默认为单例模式。
- 工厂模式：BeanFactory就是简单工厂模式的体现，用来创建对象的实例；
- 代理模式：Spring的AOP功能用到了JDK的动态代理和CGLIB字节码生成技术；
- 模板方法：用来解决代码重复的问题。比如，RestTemplate, JmsTemplate, JpaTemplate。
- 观察者模式：定义对象键一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都会得到通知被制动更新，如Spring中listener的实现–ApplicationListener。
- 装饰器模式
- 适配器模式
- 策略模式
以下讲解Spring中涉及的各种设计模式的使用场景和实现原理等。
一、工厂模式
1.1 简单工厂
1.1.1 使用场景
BeanFactory
Spring中的BeanFactory就是简单工厂模式的体现，根据传入一个唯一的标识来获得Bean对象，但是否是在传入参数后创建还是传入参数前创建这个要根据具体情况来定。
简单工厂有3个角色：抽象产品、具体产品、具体工厂
实质：由一个工厂类根据传入的参数，动态决定应该创建哪一个产品类。
1.1.2 实现原理
1） bean容器的启动阶段：
- 读取bean的xml配置文件，将bean元素分别转换成一个BeanDefinition对象。
- 然后通过BeanDefinitionRegistry将这些bean注册到beanFactory中，保存在它的一个ConcurrentHashMap中。
- 将BeanDefinition注册到了beanFactory之后，在这里Spring为我们提供了一个扩展的接口，允许我们通过实现接口BeanFactoryPostProcessor 在此处来插入我们定义的代码。典型的例子就是：PropertyPlaceholderConfigurer，我们一般在配置数据库的dataSource时使用到的占位符的值，就是它注入进去的。
2）容器中bean的实例化阶段：
实例化阶段主要是通过反射或者CGLIB对bean进行实例化，在这个阶段Spring又给我们暴露了很多的扩展点：
- 各种的Aware接口，比如 BeanFactoryAware，对于实现了这些Aware接口的bean，在实例化bean时Spring会帮我们注入对应的BeanFactory的实例。
- BeanPostProcessor接口，实现了BeanPostProcessor接口的bean，在实例化bean时Spring会帮我们调用接口中的方法。
- InitializingBean接口，实现了InitializingBean接口的bean，在实例化bean时Spring会帮我们调用接口中的方法。
- DisposableBean接口，实现了DisposableBean接口的bean，在该bean死亡时Spring会帮我们调用接口中的方法。
1.1.3 设计意义
- 松耦合
可以将原来硬编码的依赖，通过Spring这个beanFactory这个工厂来注入依赖，也就是说原来只有依赖方和被依赖方，现在我们引入了第三方——spring这个beanFactory，由它来解决bean之间的依赖问题，达到了松耦合的效果。 - bean的额外处理
通过Spring接口的暴露，在实例化bean的阶段我们可以进行一些额外的处理，这些额外的处理只需要让bean实现对应的接口即可，那么spring就会在bean的生命周期调用我们实现的接口来处理该bean。
1.2 工厂方法
1.2.1 使用场景
FactoryBean接口
BeanFactory 简介以及它 和FactoryBean的区别(阿里面试)
这篇文章中有代码实例，如果觉得不详细可以另行查阅。
1.2.2 实现原理
实现了FactoryBean接口的bean是一类叫做factory的bean。其特点是，spring会在使用getBean()调用获得该bean时，会自动调用该bean的getObject()方法，所以返回的不是factory这个bean，而是这个bean.getObject()方法的返回值。
工厂方法有四个角色：抽象工厂、具体工厂、抽象产品、具体产品。
FactoryBean接口就是抽象工厂，实现了FactoryBean接口的bean就是具体工厂，bean.getObject()方法的返回值就是抽象产品的实例，最后类型转换为具体产品。
例子：
典型的例子有spring与mybatis的结合。
代码示例：
说明：
我们看上面该bean，因为实现了FactoryBean接口，所以返回的不是 SqlSessionFactoryBean 的实例，而是它的 SqlSessionFactoryBean.getObject() 的返回值。
1.3 抽象工厂
Spring中没有典型应用，这里列出来是和简单工厂、工厂方法有一个对比。
参考：简单工厂、工厂方法、抽象工厂之小结、区别
简单工厂、工厂方法、抽象工厂之间的对比需要掌握，上面这篇简洁明了。
二、单例模式
单例模式的各种实现方式可以参考：Java多线程从零开始 这篇文章的第六节。
2.1 使用场景：依赖注入(DI)
Spring依赖注入Bean实例默认是单例的。
Spring的依赖注入（包括lazy-init方式）都是发生在AbstractBeanFactory的getBean里。getBean的doGetBean方法调用getSingleton进行bean的创建。
2.2 分析getSingleton()方法
public Object getSingleton(String beanName){
//参数true设置标识允许早期依赖
return getSingleton(beanName,true);
}
protected Object getSingleton(String beanName, boolean allowEarlyReference) {
//检查缓存中是否存在实例
Object singletonObject = this.singletonObjects.get(beanName);
if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
//如果为空，则锁定全局变量并进行处理。
synchronized (this.singletonObjects) {
//如果此bean正在加载，则不处理
singletonObject = this.earlySingletonObjects.get(beanName);
if (singletonObject == null && allowEarlyReference) {
//当某些方法需要提前初始化的时候则会调用addSingleFactory 方法将对应的ObjectFactory初始化策略存储在singletonFactories
ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
if (singletonFactory != null) {
//调用预先设定的getObject方法
singletonObject = singletonFactory.getObject();
//记录在缓存中，earlysingletonObjects和singletonFactories互斥
this.earlySingletonObjects.put(beanName, singletonObject);
this.singletonFactories.remove(beanName);
}
}
}
}
return (singletonObject != NULL_OBJECT ? singletonObject : null);
}
getSingleton()过程图
ps：spring依赖注入时，使用了 双重判断加锁（DCL） 的单例模式
2.3 总结
单例模式定义：保证一个类仅有一个实例，并提供一个访问它的全局访问点。
spring对单例的实现：spring中的单例模式完成了后半句话，即提供了全局的访问点BeanFactory。但没有从构造器级别去控制单例，这是因为spring管理的是任意的java对象。
三、适配器模式
3.1 使用场景
SpringMVC中的适配器HandlerAdatper
3.2 实现原理
HandlerAdatper根据Handler规则执行不同的Handler。
-
实现过程：
DispatcherServlet根据HandlerMapping返回的handler，向HandlerAdatper发起请求，处理Handler。
HandlerAdapter根据规则找到对应的Handler并让其执行，执行完毕后Handler会向HandlerAdapter返回一个ModelAndView，最后由HandlerAdapter向DispatchServelet返回一个ModelAndView。 -
实现意义：
HandlerAdatper使得Handler的扩展变得容易，只需要增加一个新的Handler和一个对应的HandlerAdapter即可。
因此Spring定义了一个适配接口，使得每一种Controller有一种对应的适配器实现类，让适配器代替controller执行相应的方法。
这样在扩展Controller时，只需要增加一个适配器类就完成了SpringMVC的扩展了。
四、装饰器模式
4.1 使用场景
Spring中用到的包装器模式在类名上有两种表现：一种是类名中含有Wrapper，另一种是类名中含有Decorator。
4.2 实质
动态地给一个对象添加一些额外的职责。
就增加功能来说，Decorator模式相比（Wrapper模式）生成子类更为灵活。
五、观察者模式
5.1 使用场景
spring的事件驱动模型使用的是 观察者模式，Spring中Observer模式常用的地方是listener的实现。
5.2 具体实现
事件机制的实现需要三个部分：事件源、事件、事件监听器
1）ApplicationEvent抽象类[事件]
继承自JDK的EventObject，所有的事件都需要继承ApplicationEvent，并且通过构造器参数source得到事件源。
该类的实现类ApplicationContextEvent表示ApplicaitonContext的容器事件。
代码：
public abstract class ApplicationEvent extends EventObject {
private static final long serialVersionUID = 7099057708183571937L;
private final long timestamp;
public ApplicationEvent(Object source) {
super(source);
this.timestamp = System.currentTimeMillis();
}
public final long getTimestamp() {
return this.timestamp;
}
}
2）ApplicationListener接口[事件监听器]
继承自JDK的EventListener,所有的监听器都要实现这个接口。
这个接口只有一个onApplicationEvent()方法，该方法接受一个ApplicationEvent或其子类对象作为参数，在方法体中，可以通过不同对Event类的判断来进行相应的处理。
当事件触发时所有的监听器都会收到消息。
代码：
public interface ApplicationListener<E extends ApplicationEvent> extends EventListener {
void onApplicationEvent(E event);
}
3）ApplicationContext接口[事件源]
ApplicationContext是spring中的全局IoC容器，翻译过来是”应用上下文”。
实现了ApplicationEventPublisher接口。
职责：负责读取bean的配置文档，管理bean的加载，维护bean之间的依赖关系，可以说是负责bean的整个生命周期。
代码：
public interface ApplicationEventPublisher {
void publishEvent(ApplicationEvent event);
}
public void publishEvent(ApplicationEvent event) {
Assert.notNull(event, "Event must not be null");
if (logger.isTraceEnabled()) {
logger.trace("Publishing event in " + getDisplayName() + ": " + event);
}
getApplicationEventMulticaster().multicastEvent(event);
if (this.parent != null) {
this.parent.publishEvent(event);
}
}
4）ApplicationEventMulticaster抽象类[事件源中publishEvent方法需要调用其方法getApplicationEventMulticaster]
属于事件广播器，它的作用是把ApplicationContext发布的Event广播给所有的监听器。
代码：
public abstract class AbstractApplicationContext extends DefaultResourceLoader
implements ConfigurableApplicationContext, DisposableBean {
private ApplicationEventMulticaster applicationEventMulticaster;
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 lisName : listenerBeanNames) {
getApplicationEventMulticaster().addApplicationListenerBean(lisName);
}
}
}
六、代理模式
6.1 设计模式介绍
设计模式讲解参考：设计模式—代理模式
Spring实现参考：JavaEE框架学习—Spring 第6.2节。
代理模式给某一个对象提供一个代理对象，并由代理对象控制对原对象的引用。通俗的来讲代理模式就是我们生活中常见的中介。
6.2 使用场景
AOP底层，就是动态代理模式的实现。
- 动态代理：在内存中构建的，不需要手动编写代理类
- 静态代理：需要手工编写代理类，代理类引用被代理对象。
6.2 实现原理
切面在应用运行的时刻被织入。一般情况下，在织入切面时，AOP容器会为目标对象创建动态的创建一个代理对象。Spring AOP就是以这种方式织入切面的。
织入：把切面应用到目标对象并创建新的代理对象的过程。
七、策略模式
7.1 设计模式介绍
《JAVA与模式》之策略模式
策略模式是对算法的包装，是把使用算法的责任和算法本身分割开来，委派给不同的对象管理。策略模式通常把一个系列的算法包装到一系列的策略类里面，作为一个抽象策略类的子类。用一句话来说，就是：“准备一组算法，并将每一个算法封装起来，使得它们可以互换”。
这个模式涉及到三个角色：
- 环境(Context)角色：持有一个Strategy的引用。
- 抽象策略(Strategy)角色：这是一个抽象角色，通常由一个接口或抽象类实现。此角色给出所有的具体策略类所需的接口。
- 具体策略(ConcreteStrategy)角色：包装了相关的算法或行为。
代码示例：
//抽象策略类
public interface Strategy {
//策略方法
public void strategyInterface();
}
//具体策略类
public class ConcreteStrategyA implements Strategy {
@Override
public void strategyInterface() {
//相关的业务
}
}
public class ConcreteStrategyB implements Strategy {
@Override
public void strategyInterface() {
//相关的业务
}
}
//环境角色类
public class Context {
//持有一个具体策略的对象
private Strategy strategy;
/**
* 构造函数，传入一个具体策略对象
* @param strategy 具体策略对象
*/
public Context(Strategy strategy){
this.strategy = strategy;
}
//策略方法
public void contextInterface(){
strategy.strategyInterface();
}
}
//主函数
public class StrategyPatternDemo {
public static void main(String[] args) {
Context context = new Context(new ConcreteStrategyA());
context.contextInterface();
context = new Context(new ConcreteStrategyB());
context.contextInterface();
}
}
简单地说，策略模式的核心就是利用继承和多态特性，或者switch等选择语句，可以提高调用方（也就是环境角色类）的灵活性。
7.2 使用场景
Spring框架的资源访问Resource接口 。该接口提供了更强的资源访问能力，Spring 框架本身大量使用了 Resource 接口来访问底层资源。
7.3 Resource 接口介绍
Resource 接口是具体资源访问策略的抽象，也是所有资源访问类所实现的接口。
Resource 接口主要提供了如下几个方法：
| 方法 | 描述 |
|---|---|
| getInputStream() | 定位并打开资源，返回资源对应的输入流。每次调用都返回新的输入流。调用者必须负责关闭输入流。 |
| exists() | 返回 Resource 所指向的资源是否存在。 |
| isOpen() | 返回资源文件是否打开，如果资源文件不能多次读取，每次读取结束应该显式关闭，以防止资源泄漏。 |
| getDescription() | 返回资源的描述信息，通常用于资源处理出错时输出该信息，通常是全限定文件名或实际 URL。 |
| getFile() | 返回资源对应的 File 对象。 |
| getURL() | 返回资源对应的 URL 对象。 |
最后两个方法通常无须使用，仅在通过简单方式访问无法实现时，Resource 提供传统的资源访问的功能。
Resource 接口本身没有提供访问任何底层资源的实现逻辑，针对不同的底层资源，Spring 将会提供不同的 Resource 实现类，不同的实现类负责不同的资源访问逻辑。
Spring 为 Resource 接口提供了如下实现类：
| 类名 | 描述 |
|---|---|
| UrlResource | 访问网络资源的实现类。 |
| ClassPathResource | 访问类加载路径里资源的实现类。 |
| FileSystemResource | 访问文件系统里资源的实现类。 |
| ServletContextResource | 访问相对于 ServletContext 路径里的资源的实现类。 |
| InputStreamResource | 访问输入流资源的实现类。 |
| ByteArrayResource | 访问字节数组资源的实现类。 |
这些 Resource 实现类，针对不同的的底层资源，提供了相应的资源访问逻辑，并提供便捷的包装，以利于客户端程序的资源访问。
八、模版方法模式
8.1 设计模式介绍
模板方法模式是一种行为设计模式，它定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以在不改变一个算法的结构即可重定义该算法的默写特定步骤的实现方式。
- 特点：父类定义了骨架（调用哪些方法及顺序），某些特定方法由子类实现。
- 好处：代码复用，减少重复代码。除了子类要实现的特定方法，其他方法及方法调用顺序都在父类中预先写好了。
因此，父类模板方法中有两类方法：
1）共同的方法：所有子类都会用到的代码
2）不同的方法：子类要覆盖的方法，分为两种：
- 抽象方法：父类中的是抽象方法，子类必须覆盖
- 钩子方法：父类中是一个空方法，子类继承了默认也是空的
注：为什么叫钩子，子类可以通过这个钩子（方法），控制父类，因为这个钩子实际是父类的方法（空方法）！
代码示例
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() {
//子类实现
}
8.2 Spring模板方法实质
实质上是模板方法模式和回调方法的结合，是Template Method不需要继承的另一种实现方式。Spring几乎所有的外接扩展都采用这种模式。
8.3 具体实现
JDBC的抽象和对Hibernate的集成，都采用了一种理念或者处理方式，那就是模板方法模式与相应的Callback接口相结合。
采用模板方法模式是为了以一种统一而集中的方式来处理资源的获取和释放，以JdbcTemplate为例:
public abstract class JdbcTemplate {
public final Object execute(String sql){
Connection con=null;
Statement stmt=null;
try{
con=getConnection();
stmt=con.createStatement();
Object retValue=executeWithStatement(stmt,sql);
return retValue;
}catch(SQLException e){
...
}finally{
closeStatement(stmt);
releaseConnection(con);
}
}
protected abstract Object executeWithStatement(Statement stmt, String sql);
}
引入回调原因：
JdbcTemplate是抽象类，不能够独立使用，我们每次进行数据访问的时候都要给出一个相应的子类实现,这样肯定不方便，所以就引入了回调 。
回调代码：
public interface StatementCallback{
Object doWithStatement(Statement stmt);
}
利用回调方法重写 JdbcTemplate 方法：
public class JdbcTemplate {
public final Object execute(StatementCallback callback){
Connection con=null;
Statement stmt=null;
try{
con=getConnection();
stmt=con.createStatement();
Object retValue=callback.doWithStatement(stmt);
return retValue;
}catch(SQLException e){
...
}finally{
closeStatement(stmt);
releaseConnection(con);
}
}
//其它方法定义
Object executeWithStatement(Statement stmt, String sql){
return ...;
}
}
Jdbc使用方法如下：
JdbcTemplate jdbcTemplate=...;
final String sql=...;
//匿名内部类形式创建callback对象，重写doWithStatement方法
StatementCallback callback=new StatementCallback(){
@Override
public Object doWithStatement(Statement stmt){
//回调的作用在这里体现：stmt是JdbcTemplate内部的变量，sql是当前执行环境的变量
//jdbcTemplate的execute方法以传参形式将stmt传递给callback对象并调用callback的doWithStatement方法，
//然后doWithStatement函数处理好stmt(即后面这行代码)后返回到execute上下文
Object res=jdbcTemplate.executeWithStatement(stmt,sql);
return res;
}
}
//execute返回结果完成回调
Object result = jdbcTemplate.execute(callback);
为什么JdbcTemplate没有使用继承？
因为这个类的方法太多，但是我们还是想用到JdbcTemplate已有的稳定的、公用的数据库连接，那么我们怎么办呢？
我们可以把变化的东西抽出来作为一个参数传入JdbcTemplate的方法中。但是变化的东西是一段代码，而且这段代码会用到JdbcTemplate中的变量。怎么办？
那我们就用回调对象吧。在这个回调对象中定义一个操纵JdbcTemplate中变量的方法，我们去实现这个方法，就把变化的东西集中到这里了。然后我们再传入这个回调对象到JdbcTemplate，从而完成了调用。
9161
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
