Spring中经典的9种设计模式Word格式.docx

上传人:b****6 文档编号:21546056 上传时间:2023-01-31 格式:DOCX 页数:10 大小:247.77KB
下载 相关 举报
Spring中经典的9种设计模式Word格式.docx_第1页
第1页 / 共10页
Spring中经典的9种设计模式Word格式.docx_第2页
第2页 / 共10页
Spring中经典的9种设计模式Word格式.docx_第3页
第3页 / 共10页
Spring中经典的9种设计模式Word格式.docx_第4页
第4页 / 共10页
Spring中经典的9种设计模式Word格式.docx_第5页
第5页 / 共10页
点击查看更多>>
下载资源
资源描述

Spring中经典的9种设计模式Word格式.docx

《Spring中经典的9种设计模式Word格式.docx》由会员分享,可在线阅读,更多相关《Spring中经典的9种设计模式Word格式.docx(10页珍藏版)》请在冰豆网上搜索。

Spring中经典的9种设计模式Word格式.docx

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

代码示例:

说明:

我们看上面该bean,因为实现了FactoryBean接口,所以返回的不是SqlSessionFactoryBean的实例,而是它的SqlSessionFactoryBean.getObject()的返回值。

3.单例模式

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

Spring的依赖注入(包括lazy-init方式)都是发生在AbstractBeanFactory的getBean里。

getBean的doGetBean方法调用getSingleton进行bean的创建。

分析getSingleton()方法

public 

Object 

getSingleton(String 

beanName){ 

 

//参数true设置标识允许早期依赖 

return 

getSingleton(beanName,true);

protected 

beanName, 

boolean 

allowEarlyReference) 

//检查缓存中是否存在实例 

singletonObject 

this.singletonObjects.get(beanName);

if 

(singletonObject 

== 

null 

&

isSingletonCurrentlyInCreation(beanName)) 

//如果为空,则锁定全局变量并进行处理。

synchronized 

(this.singletonObjects) 

//如果此bean正在加载,则不处理 

this.earlySingletonObjects.get(beanName);

//当某些方法需要提前初始化的时候则会调用addSingleFactory 

方法将对应的ObjectFactory初始化策略存储在singletonFactories 

ObjectFactory<

?

>

singletonFactory 

this.singletonFactories.get(beanName);

(singletonFactory 

!

null) 

//调用预先设定的getObject方法 

singletonFactory.getObject();

//记录在缓存中,earlysingletonObjects和singletonFactories互斥 

this.earlySingletonObjects.put(beanName, 

singletonObject);

this.singletonFactories.remove(beanName);

NULL_OBJECT 

:

null);

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模式常用的地方是listener的实现。

具体实现:

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

ApplicationEvent抽象类[事件]

继承自jdk的EventObject,所有的事件都需要继承ApplicationEvent,并且通过构造器参数source得到事件源.

该类的实现类ApplicationContextEvent表示ApplicaitonContext的容器事件.

代码:

abstract 

class 

ApplicationEvent 

extends 

EventObject 

private 

static 

final 

long 

serialVersionUID 

7099057708183571937L;

timestamp;

ApplicationEvent(Object 

source) 

super(source);

this.timestamp 

System.currentTimeMillis();

getTimestamp() 

this.timestamp;

ApplicationListener接口[事件监听器]

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

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

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

interface 

ApplicationListener<

ApplicationEvent>

EventListener 

void 

onApplicationEvent(E 

event);

ApplicationContext接口[事件源]

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

实现了ApplicationEventPublisher接口。

职责:

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

ApplicationEventPublisher 

publishEvent(ApplicationEvent 

event) 

Assert.notNull(event, 

"

Event 

must 

not 

be 

null"

);

(logger.isTraceEnabled()) 

logger.trace("

Publishing 

event 

in 

getDisplayName() 

getApplicationEventMulticaster().multicastEvent(event);

(this.parent 

this.parent.publishEvent(event);

ApplicationEventMulticaster抽象类[事件源中publishEvent方法需要调用其方法getApplicationEventMulticaster]

属于事件广播器,它的作用是把Applicationcontext发布的Event广播给所有的监听器.

AbstractApplicationContext 

DefaultResourceLoader 

implements 

ConfigurableApplicationContext, 

DisposableBean 

ApplicationEventMulticaster 

applicationEventMulticaster;

registerListeners() 

// 

Register 

statically 

specified 

listeners 

first. 

for 

(ApplicationListener<

listener 

getApplicationListeners()) 

getApplicationEventMulticaster().addApplicationListener(listener);

Do 

initialize 

FactoryBeans 

here:

We 

need 

to 

leave 

all 

regular 

beans 

uninitialized 

let 

post-processors 

apply 

them!

String[] 

listenerBeanNames 

getBeanNamesForType(ApplicationListener.class, 

true, 

false);

(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模板方法模式实质:

是模板方法模式和回调模式的结合,是TemplateMethod不需要继承的另一种实现方式。

Spring几乎所有的外接扩展都采用这种模式。

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

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

JdbcTemplate 

execute(String 

sql){ 

Connection 

con=null;

Statement 

stmt=null;

try{ 

con=getConnection();

stmt=con.createStatement();

retValue=executeWithStatement(stmt,sql);

retValue;

}catch(SQLException 

e){ 

... 

}finally{ 

closeStatement(stmt);

releaseConnection(con);

executeWithStatement(Statement 

stmt, 

String 

sql);

引入回调原因:

JdbcTemplate是抽象类,不能够独立使用,我们每次进行数据访问的时候都要给出一个相应的子类实现,这样肯定不方便,所以就引入了回调。

回调代码

StatementCallback{ 

doWithStatement(Statement 

stmt);

利用回调方法重写JdbcTemplate方法

execute(StatementCallback 

callback){ 

retValue=callback.doWithStatement(stmt);

...//其它方法定义 

Jdbc使用方法如下:

jdbcTemplate=...;

sql=...;

S

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 表格模板 > 合同协议

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1