七. SpringBean 的设计模式?
7.1 简单工厂(非23种设计模式中的一种)
- 实现方式:BeanFactory。 Spring中的BeanFactory就是简单工厂模式的体现,根据传入一个唯一的标识来获得Bean对象,但是在传入参数后创建,还是传入参数前创建,这个要根据具体情况来定。
- 实质:由一个工厂类根据传入的参数,动态决定应该创建哪一个产品类。
- 设计意义:
- 松耦合。可以将原来硬编码的依赖,通过Spring这个beanFactory这个工厂来注入依赖,也就是说原来只有依赖方和被依赖方,现在我们引入了第三方——spring这个beanFactory,由它来解决bean之间的依赖问题,达到了松耦合的效果.
- bean的额外处理。通过Spring接口的暴露,在实例化bean的阶段我们可以进行一些额外的处理,这些额外的处理只需要让bean实现对应的接口即可,那么spring就会在bean的生命周期调用我们实现的接口来处理该bean。[非常重要]
7.2 工厂方法
- 实现方式:FactoryBean接口。
- 实现原理:
- 实现了 FactoryBean 接口的 bean 是工厂类的 Bean,其特点是,Spring 会在使用 getBean() 调用获得该 bean 时,会自动调用该 bean 的 getObject() 方法,所以返回的不是工厂类,而是调用这个工厂类 bean.getOjbect() 方法的返回值。
- 例子:
- 典型的例子有 spring 与 mybatis 的结合,Mybatis 使用 SqlSessionFactoryBean 调用
getObject()
方法创建 SqlSessionFactory。 - 代码示例
- 典型的例子有 spring 与 mybatis 的结合,Mybatis 使用 SqlSessionFactoryBean 调用
<bean id="sqlSessionFactory" class="org.mybatis.spring.SqlSessionFactoryBean">
<property name="dataSource" ref="dataSource"/>
<property name="configLocation" value="classpath:config/mybatis-config-master.xml"/>
<property name="mapperLocations" value="classpath:config/mappers/master/**/*.xml"/>
</bean>
说明:我们看上面的 bean,因为实现了 FactoryBean 接口,所以返回的不是 SqlSessionFactoryBean 的实例,而是它的 SqlSessionFactoryBean.getObject() 的返回值。
7.3 单例模式
- 单例模式定义:保证一个类仅有一个实例,并提供一个访问它的全局访问点。
- spring 对单例的实现:spring 中的单例模式完成了后半句话,即提供了全局的访问点BeanFactory。但没有从构造器级别去控制单例,这是因为 Spring 管理的是任意的 java 对象。
- Spring 依赖注入 Bean 实例默认是单例的。
- Spring 的依赖注入(包括 lazy-init 方式)都是发生在 AbstractBeanFactory 的
getBean()
里。getBean()
的doGetBean()
方法调用getSingleton()
进行 bean 的创建。
注:单例模式的依赖注入部分见《框架》篇第一章。
7.4 适配器模式
- 例 1:SpringMVC 中的适配器 HandlerAdatper。
- 实现原理:HandlerAdatper 根据 Handler 规则,执行不同的 Handler。
- 实现过程:
- 实现过程见《框架》篇第三章。
- 实现意义:
- HandlerAdatper 使得 Handler 的扩展变得容易,只需要增加一个新的 Handler 和一个对应的 HandlerAdapter 即可。
- 因此 Spring 定义了一个适配接口,使得每一种 Controller 有一种对应的适配器实现类,让适配器代替 Controller 执行相应的方法。这样在扩展 Controller 时,只需要增加一个适配器类,就完成了 SpringMVC 的扩展了。例如:
- SimpleControllerHandlerAdapter:继承 Controller 接口所使用的适配器;
- HttpRequestHandlerAdapter:HTTP 请求处理器适配器;
- RequestMappingHandlerAdapter:注解方式(@Controller)的处理器适配器;
7.5 装饰器模式
- 实现方式:
- Spring 中用到的包装器模式在类名上有两种表现:一种是类名中含有 Wrapper,另一种是类名中含有 Decorator。
- 实质:
- 动态地给一个对象添加一些额外的职责。
- 就增加功能来说,Decorator 模式相比生成子类更为灵活。
7.6 代理模式
- 例 1:AOP 底层,就是代理模式的实现。
- Spring AOP 有两种模式:
- 动态代理:在内存中构建的,不需要手动编写代理类
- 静态代理:需要手工编写代理类,代理类引用被代理对象。
- 实现原理:
- 切面在应用运行的时刻被织入。一般情况下,在织入切面时,AOP 容器会为目标对象创建动态的创建一个代理对象。SpringAOP 就是以这种方式织入切面的。
- 织入:把切面应用到目标对象并创建新的代理对象的过程。
- 代理模式见[第二章《代理模式》](#二. 代理模式)。
- Spring AOP 有两种模式:
7.7 观察者模式
-
实现方式:Spring 的事件驱动模型使用的是观察者模式 (Observer),具体实现需要四个部分:事件源,事件,事件监听器,事件广播器:
-
事件:ApplicationEvent 抽象类
- JDK 中继承于 EventObject,在 Spring 框架中所有的事件都需要继承 ApplicationEvent,并且通过构造器参数 source 得到事件源。
- 在 Spring 框架中主要使用的事件类,是 ApplicationEvent 的实现类 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 中的全局容器,翻译过来是”应用上下文”。
- ApplicationContext 实现了 ApplicationEventPublisher 接口。
- 职责:ApplicationContext 说通俗一点,就是我们平时所说的 IoC 容器。除了作为观察者模式的事件源之外,它还负责读取 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);
}
}
- 事件广播器:ApplicationEventMulticaster 抽象类
- 事件源 ApplicationContext 中,
publishEvent()
方法需要调用其方法getApplicationEventMulticaster()
; - ApplicationEventMulticaster 属于事件广播器,它的作用是把 ApplicationContext 发布的 Event 广播给所有的监听器。
- 代码:
- 事件源 ApplicationContext 中,
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);
}
}
}
7.8 策略模式
- 实现方式:Spring 框架的资源访问 Resource 接口。该接口提供了更强的资源访问能力,Spring 框架本身大量使用了 Resource 接口来访问底层资源。
- 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 实现类,针对不同的的底层资源,提供了相应的资源访问逻辑,并提供便捷的包装,以利于客户端程序的资源访问。
7.9 模版方法模式
- 经典模板方法定义:
- 父类定义了骨架(调用哪些方法及顺序),某些特定方法由子类实现
- 最大的好处:代码复用,减少重复代码。除了子类要实现的特定方法,其他方法及方法调用顺序都在父类中预先写好了。
- 所以父类模板方法中有两类方法:
- 共同的方法:所有子类都会用到的代码
- 不同的方法:子类要覆盖的方法,分为两种:
- 抽象方法:父类中的是抽象方法,子类必须覆盖
- 钩子方法:父类中是一个空方法,子类继承了默认也是空的
- 注:为什么叫钩子,子类可以通过这个钩子(方法),控制父类,因为这个钩子实际是父类的方法(空方法)!
- 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,从而完成了调用。