1.简单工厂(非23种设计模式中的一种)
实现方式:
BeanFactory
。Spring中的 BeanFactory
就是简单工厂模式的体现,根据传入一个唯一的标识来获得Bean对象,但是否是在传入参数后创建还是传入参数前创建这个要根据具体情况来定。
###了实质:由一个工厂类根据传入的参数,动态决定应该创建哪一个产品类。
实现原理:
bean容器的启动阶段:
读取bean的xml配置文件,将bean元素分别转换成一个 BeanDefinition
对象。
然后通过 BeanDefinitionRegistry
将这些bean注册到beanFactory中,保存在它的一个Con currentHashMap
中。
将 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会帮我们调用接口中的方法。
设计意义:
松耦合。可以将原来硬编码的依赖,通过Spring这个 beanFactory
这个工厂来注入依赖,也就是说原来只有依赖方和被依赖方,现在我们引入了第三方——spring这个 beanFactory
,由它来解决bean之间的依赖问题,达到了松耦合的效果.
bean的额外处理。通过Spring接口的暴露,在实例化bean的阶段我们可以进行一些额外的处理,这些额外的处理只需要让bean实现对应的接口即可,那么spring就会在bean的生命周期调用我们实现的接口来处理该bean。 [非常重要]
2.工厂方法
实现方式:
FactoryBean接口。
实现原理:实现了 FactoryBean
接口的bean是一类叫做factory的bean。其特点是,spring会在使用getBean()调用获得该bean时,会自动调用该bean的 getObject()
方法,所以返回的不是factory这个bean,而是这个 bean.getOjbect()
方法的返回值。
例子:典型的例子有spring与mybatis的结合。
代码示例:
说明:
我们看上面该bean,因为实现了 FactoryBean
接口,所以返回的不是 SqlSessionFactoryBean
的实例,而是它的 SqlSessionFactoryBean.getObject()
的返回值。
3.单例模式
Spring依赖注入Bean实例默认是单例的。
Spring的依赖注入(包括lazy-init方式)都是发生在 AbstractBeanFactory
的getBean里。getBean的 doGetBean
方法调用 getSingleton
进行bean的创建。
分析 getSingleton()
方法
getSingleton()过程图
ps:spring依赖注入时,使用了 双重判断加锁 的单例模式
总结
单例模式定义:保证一个类仅有一个实例,并提供一个访问它的全局访问点。
spring对单例的实现:spring中的单例模式完成了后半句话,即提供了全局的访问点 BeanFactory
。但没有从构造器级别去控制单例,这是因为spring管理的是任意的java对象。
4.适配器模式
实现方式:
SpringMVC中的适配器 HandlerAdatper
。
实现原理:
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
的扩展了。
5.装饰器模式
实现方式:
Spring中用到的包装器模式在类名上有两种表现:一种是类名中含有 Wrapper
,另一种是类名中含有 Decorator
。
实质:
动态地给一个对象添加一些额外的职责。
就增加功能来说, Decorator
模式相比生成子类更为灵活。
6.代理模式
实现方式:
AOP
底层,就是动态代理模式的实现。
动态代理:
在内存中构建的,不需要手动编写代理类
静态代理:
需要手工编写代理类,代理类引用被代理对象。
实现原理:
切面在应用运行的时刻被织入。一般情况下,在织入切面时, AOP
容器会为目标对象创建动态的创建一个代理对象。 SpringAOP
就是以这种方式织入切面的。
织入:把切面应用到目标对象并创建新的代理对象的过程。
7.观察者模式
实现方式:
spring的事件驱动模型使用的是 观察者模式 ,Spring中 Observer
模式常用的地方是l istener
的实现。
具体实现:
事件机制的实现需要三个部分:事件源、事件、事件监听器
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);
}
}
}
8.策略模式
实现方式:
Spring框架的资源访问 Resource
接口。该接口提供了更强的资源访问能力,Spring 框架本身大量使用了 Resource
接口来访问底层资源。
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
实现类,针对不同的的底层资源,提供了相应的资源访问逻辑,并提供便捷的包装,以利于客户端程序的资源访问。
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
,从而完成了调用。