7.观察者模式
实现方式：
spring的事件驱动模型使用的是 观察者模式 ，Spring中Observer模式常用的地方是listener的实现。
具体实现：
事件机制的实现需要三个部分,事件源,事件,事件监听器
ApplicationEvent抽象类[事件]
继承自jdk的EventObject,所有的事件都需要继承ApplicationEvent,并且通过构造器参数source得到事件源.
该类的实现类ApplicationContextEvent表示ApplicaitonContext的容器事件.
代码：
publicabstractclass ApplicationEvent extends EventObject { privatestaticfinallong serialVersionUID = 7099057708183571937L; privatefinallong timestamp; public ApplicationEvent(Object source) { super(source); this.timestamp = System.currentTimeMillis(); } public final long getTimestamp() { returnthis.timestamp; } }
ApplicationListener接口[事件监听器]
继承自jdk的EventListener,所有的监听器都要实现这个接口。
这个接口只有一个onApplicationEvent()方法,该方法接受一个ApplicationEvent或其子类对象作为参数,在方法体中,可以通过不同对Event类的判断来进行相应的处理。
当事件触发时所有的监听器都会收到消息。
代码：
publicinterface ApplicationListener<E extends ApplicationEvent> extends EventListener { void onApplicationEvent(E event); }
ApplicationContext接口[事件源]
ApplicationContext是spring中的全局容器，翻译过来是”应用上下文”。
实现了ApplicationEventPublisher接口。
职责：
负责读取bean的配置文档,管理bean的加载,维护bean之间的依赖关系,可以说是负责bean的整个生命周期,再通俗一点就是我们平时所说的IOC容器。
代码：
publicinterface 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广播给所有的监听器.
代码：
publicabstractclass 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为例:
publicabstractclass JdbcTemplate { publicfinal 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）; } } protectedabstract Object executeWithStatement（Statement stmt, String sql）; }
引入回调原因：
JdbcTemplate是抽象类，不能够独立使用，我们每次进行数据访问的时候都要给出一个相应的子类实现,这样肯定不方便，所以就引入了回调。
回调代码
publicinterface StatementCallback{ Object doWithStatement（Statement stmt）; }
利用回调方法重写JdbcTemplate方法
publicclass JdbcTemplate { publicfinal 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，从而完成了调用。
