Spring中必定要掌握的9种设计模式

一、简单工厂(非23种设计模式中的一种)

1）实现方式：

BeanFactory。Spring中的BeanFactory就是简单工厂模式的体现，根据传入一个惟一的标识来得到Bean对象，可是否是在传入参数后建立仍是传入参数前建立这个要根据具体状况来定。

实质：

由一个工厂类根据传入的参数，动态决定应该建立哪个产品类。

2）实现原理：

bean容器的启动阶段：

读取bean的xml配置文件,将bean元素分别转换成一个BeanDefinition对象。

而后经过BeanDefinitionRegistry将这些bean注册到beanFactory中，保存在它的一个ConcurrentHashMap中。

将BeanDefinition注册到了beanFactory以后，在这里Spring为咱们提供了一个扩展的切口，容许咱们经过实现接口BeanFactoryPostProcessor 在此处来插入咱们定义的代码。典型的例子就是：PropertyPlaceholderConfigurer，咱们通常在配置数据库的dataSource时使用到的占位符的值，就是它注入进去的。

容器中bean的实例化阶段：

实例化阶段主要是经过反射或者CGLIB对bean进行实例化，在这个阶段Spring又给咱们暴露了不少的扩展点：

各类的Aware接口，好比 BeanFactoryAware，对于实现了这些Aware接口的bean，在实例化bean时Spring会帮咱们注入对应的BeanFactory的实例。

BeanPostProcessor接口，实现了BeanPostProcessor接口的bean，在实例化bean时Spring会帮咱们调用接口中的方法。
InitializingBean接口，实现了InitializingBean接口的bean，在实例化bean时Spring会帮咱们调用接口中的方法。

DisposableBean接口，实现了BeanPostProcessor接口的bean，在该bean死亡时Spring会帮咱们调用接口中的方法。

3）设计意义：

松耦合。

能够将原来硬编码的依赖，经过Spring这个beanFactory这个工厂来注入依赖，也就是说原来只有依赖方和被依赖方，如今咱们引入了第三方——spring这个beanFactory，由它来解决bean之间的依赖问题，达到了松耦合的效果.

bean的额外处理。

经过Spring接口的暴露，在实例化bean的阶段咱们能够进行一些额外的处理，这些额外的处理只须要让bean实现对应的接口便可，那么spring就会在bean的生命周期调用咱们实现的接口来处理该bean。

二、工厂方法

1）实现方式：

FactoryBean接口。

2）实现原理：

实现了FactoryBean接口的bean是一类叫作factory的bean。其特色是，spring会在使用getBean()调用得到该bean时，会自动调用该bean的getObject()方法，因此返回的不是factory这个bean，而是这个bean.getOjbect()方法的返回值。

例子：

典型的例子有spring与mybatis的结合。

3）代码示例：

说明：

咱们看上面该bean，由于实现了FactoryBean接口，因此返回的不是 SqlSessionFactoryBean 的实例，而是它的 SqlSessionFactoryBean.getObject() 的返回值。

三、单例模式

Spring依赖注入Bean实例默认是单例的。

Spring的依赖注入（包括lazy-init方式）都是发生在AbstractBeanFactory的getBean里。getBean的doGetBean方法调用getSingleton进行bean的建立。

分析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依赖注入时，使用了 双重判断加锁 的单例模式

总结

单例模式定义：保证一个类仅有一个实例，并提供一个访问它的全局访问点。

spring对单例的实现：spring中的单例模式完成了后半句话，即提供了全局的访问点BeanFactory。但没有从构造器级别去控制单例，这是由于spring管理的是任意的java对象。

四、适配器模式

1）实现方式：

SpringMVC中的适配器HandlerAdatper。

2）实现原理：

HandlerAdatper根据Handler规则执行不一样的Handler。

3）实现过程：

DispatcherServlet根据HandlerMapping返回的handler，向HandlerAdatper发起请求，处理Handler。

HandlerAdapter根据规则找到对应的Handler并让其执行，执行完毕后Handler会向HandlerAdapter返回一个ModelAndView，最后由HandlerAdapter向DispatchServelet返回一个ModelAndView。

4）实现意义：

HandlerAdatper使得Handler的扩展变得容易，只须要增长一个新的Handler和一个对应的HandlerAdapter便可。

所以Spring定义了一个适配接口，使得每一种Controller有一种对应的适配器实现类，让适配器代替controller执行相应的方法。这样在扩展Controller时，只须要增长一个适配器类就完成了SpringMVC的扩展了。

五、装饰器模式

1）实现方式：

Spring中用到的包装器模式在类名上有两种表现：一种是类名中含有Wrapper，另外一种是类名中含有Decorator。

2）实质：

动态地给一个对象添加一些额外的职责。

就增长功能来讲，Decorator模式相比生成子类更为灵活。

六、代理模式

1）实现方式：

AOP底层，就是动态代理模式的实现。

2）动态代理：

在内存中构建的，不须要手动编写代理类

3）静态代理：

须要手工编写代理类，代理类引用被代理对象。

4）实现原理：

切面在应用运行的时刻被织入。通常状况下，在织入切面时，AOP容器会为目标对象建立动态的建立一个代理对象。SpringAOP就是以这种方式织入切面的。

织入：把切面应用到目标对象并建立新的代理对象的过程。

七、观察者模式

1）实现方式：

spring的事件驱动模型使用的是 观察者模式 ，Spring中Observer模式经常使用的地方是listener的实现。

2）具体实现：

事件机制的实现须要三个部分,事件源,事件,事件监听器

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;
    }
}

ApplicationListener接口[事件监听器]

继承自jdk的EventListener,全部的监听器都要实现这个接口。

这个接口只有一个onApplicationEvent()方法,该方法接受一个ApplicationEvent或其子类对象做为参数,在方法体中,能够经过不一样对Event类的判断来进行相应的处理。

当事件触发时全部的监听器都会收到消息。

代码：

public interface ApplicationListener<E extends ApplicationEvent> extends EventListener {
     void onApplicationEvent(E event);
}
ApplicationContext接口[事件源]

ApplicationContext是spring中的全局容器，翻译过来是”应用上下文”。

实现了ApplicationEventPublisher接口。

职责：

负责读取bean的配置文档,管理bean的加载,维护bean之间的依赖关系,能够说是负责bean的整个生命周期,再通俗一点就是咱们平时所说的IOC容器。

代码：

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);
    }
}

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);  
    }  
  }  
}

八、策略模式

1）实现方式：

Spring框架的资源访问Resource接口。该接口提供了更强的资源访问能力，Spring 框架自己大量使用了 Resource 接口来访问底层资源。

2）Resource 接口介绍

source 接口是具体资源访问策略的抽象，也是全部资源访问类所实现的接口。

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 实现类，针对不一样的的底层资源，提供了相应的资源访问逻辑，并提供便捷的包装，以利于客户端程序的资源访问。

九、模版方法模式

1）经典模板方法定义：

父类定义了骨架（调用哪些方法及顺序），某些特定方法由子类实现。

最大的好处：代码复用，减小重复代码。除了子类要实现的特定方法，其余方法及方法调用顺序都在父类中预先写好了。

因此父类模板方法中有两类方法：

共同的方法：全部子类都会用到的代码

不一样的方法：子类要覆盖的方法，分为两种：

抽象方法：父类中的是抽象方法，子类必须覆盖

钩子方法：父类中是一个空方法，子类继承了默认也是空的

注：为何叫钩子，子类能够经过这个钩子（方法），控制父类，由于这个钩子实际是父类的方法（空方法）！

2）Spring模板方法模式实质：

是模板方法模式和回调模式的结合，是Template Method不须要继承的另外一种实现方式。Spring几乎全部的外接扩展都采用这种模式。

具体实现：

JDBC的抽象和对Hibernate的集成，都采用了一种理念或者处理方式，那就是模板方法模式与相应的Callback接口相结合。

采用模板方法模式是为了以一种统一而集中的方式来处理资源的获取和释放，以JdbcTempalte为例：

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）;  
        }  
    }
​
    ...//其它方法定义  
}

Jdbc使用方法以下：

JdbcTemplate jdbcTemplate=...;  
    final String sql=...;  
    StatementCallback callback=new StatementCallback(){  
    public Object=doWithStatement(Statement stmt){  
        return ...;  
    }  
}    
jdbcTemplate.execute(callback);

为何JdbcTemplate没有使用继承？

由于这个类的方法太多，可是咱们仍是想用到JdbcTemplate已有的稳定的、公用的数据库链接，那么咱们怎么办呢？

咱们能够把变化的东西抽出来做为一个参数传入JdbcTemplate的方法中。可是变化的东西是一段代码，并且这段代码会用到JdbcTemplate中的变量。怎么办？

那咱们就用回调对象吧。在这个回调对象中定义一个操纵JdbcTemplate中变量的方法，咱们去实现这个方法，就把变化的东西集中到这里了。而后咱们再传入这个回调对象到JdbcTemplate，从而完成了调用。

​文源网络，仅供学习之用，若有侵权，联系删除。 关注微信公众号：Java圈子，领取学习资料。