spring原始碼-詳解設計模式
spring中常用到的設計模式有九種，以下舉例：
第一種：簡單工廠（StaticFactory Method）
spring中的BeanFactory就是簡單工廠模式的體現，根據傳入一個唯一的標誌來獲得bean物件，但是否是在傳入引數後建立還是傳入引數前建立這個要根據具體情況來定。如下配置，就是在類中建立一個Bean。
<bean id="annotationlMessageServiceBean" class="com.cn.service.impl.AnnotationMessageServiceImpl">
<constructor-arg>
<value>Hello ! 這是annotationlMessageServiceBean！</value>
</constructor-arg>
</bean>第二種：工廠方法
通常由應用程式直接使用new建立新的物件，為了將物件的建立和使用相分離，採用工廠模式，即應用程式將物件的建立及初始化職責交給工廠物件。一般情況下，應用程式有自己的工廠物件來建立bean，如果將應用程式自己的工廠物件交給spring管理，那麼spring管理的就不是普通的bean，而是工廠bean。
就以工廠方法中的靜態方法為例講解一下：
import java.util.Random;
public class StaticFactoryBean {
public static Integer createRandom() {
return new Integer(new Random().nextInt());
}
}建立一個config.xml配置檔案，將其納入Spring容器來管理，需要通過factory-method指定靜態方法名稱
<?xml version="1.0" encoding="UTF-8" ?> <beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.springframework.org/schema/beans" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd" default-autowire="byName"> <bean id="random" class="com.cn.service.StaticFactoryBean" factory-method="createRandom" scope="prototype" /> <!-- createRandom方法必須是static的，才能找到 --> </beans>
測試：
public static void main(String[] args) {
// 建立容器物件（Bean的工廠），IOC容器 = 工廠類+ config.xml
DefaultListableBeanFactory factory = new DefaultListableBeanFactory();
// 得到容器建立的物件
XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(factory);
reader.loadBeanDefinitions(new ClassPathResource("config.xml"));
System.out.println("我是IT學習者建立的例項：" + factory.getBean("random"));
}第三種：單例模式（Singleton）
保證一個類僅有一個例項，並提供一個訪問它的全乎訪問點。spring中的單例模式完成了後半句話，即提供了全域性的訪問點BeanFactory。但沒有從構造器級別去控制單例，這是因為spring管理的是任意的java物件。
核心提示點：Spring下預設的bean均為singleton，可以通過singleton="true|false"或者 scope="?"來指定
第四種：介面卡（Adapter）
在spring的Aop中，使用的Advice（通知）來增強被代理類的功能。Spring實現這一AOP功能的原理就使用代理模式（1、JDK動態代理。2、CGLib位元組碼生成技術處理。）對類進行方法級別的切面增強，即，生成被代理類的代理類，並在代理類的方法前，設定攔截器，通過執行攔截器重的內容增強了代理方法的功能，實現面向切面變成。
Adapter類介面：Target
public interface AdvisorAdapter {
boolean supportsAdvice(Advice advice);
MethodInterceptor getInterceptor(Advisor advisor);
}MethodBeforeAdviceAdapter類，Adapter
public class MethodBeforeAdvisorAdapter implements AdvisorAdapter, Serializable {
private static final long serialVersionUID = 5727339338103580037L;
public boolean supportsAdvice(Advice advice) {
return (advice instanceof MethodBeforeAdvice);
}
public MethodInterceptor getInterceptor(Advisor advisor) {
MethodBeforeAdvice advice = (MethodBeforeAdvice) advisor.getAdvice();
return new MethodBeforeAdviceInterceptor(advice);
}
}第五種：包裝器（Decorator）
假設一個場景：專案需要連線多個數據庫，而且不同的使用者在每次訪問中根據需要回去訪問不同的資料庫。以往的操作都是在spring或mybatis框架中配置一個數據源，因而sessionFactory的dataSource屬性總是指向這個資料來源並且恆定不變，所有DAO在使用sessionFactory的時候都是通過這個資料來源訪問資料庫。但是現在，由於專案的需要。DAO在訪問sessionFactory的時候都不得不在多個數據源中來回切換，問題就出現了：如何讓sessionFactory在執行資料持久化的時候，根據使用者的需求能夠動態切換不同的資料來源？我們能不能在spring的框架下通過少量修改得到解決？是否有什麼設計模式可以利用呢？
首先想到在spring的applicationContext中配置所有的dataSource。這些dataSource可能是各種不同型別的，比如不同的資料庫：Oracle、SQL Server、MySQL等，也可能是不同的資料來源：比如apache提供的org.apache.commons.dbcp.BasicDataSource、spring提供的org.springframework.jndi.JndiObjectFactoryBean、阿里提供的com.alibaba.druid.pool.DruidDataSource等。然後sessionFactory根據客戶的每次請求，將dataSource屬性設定成不同的資料來源，以到達切換資料來源的目的。
spring中用到的包裝器模式在類名上有兩種表現：一種是類名中含有Wrapper，另一張類名中含有Decorator。基本上都是動態地給一個物件新增一些額外的職責。
第六種：代理（Proxy）
為其他物件提供一種代理以控制對這個物件的訪問。從結構上來看和Decorator模式類似，但Proxy是控制，更像是一種對功能的限制。而Decorator是增加職責。
spring的Proxy模式在aop中有體現，比如JdkDynamicAopProxy和Cglib2AopProxy。
第七種：觀察者（Observer）
定義物件間的一種一對多的依賴關係，當一個物件的狀態發生改變時，所有依賴於它的物件都得到通知並自動更新。
spring中Observer模式常用的地方是listener的實現。如ApplicationListener
第八種：策略（Strategy）
定義一系列的演算法，把它們一個個封裝起來，並且使它們可相互替換。本模式使得演算法可獨立於使用它的客戶而變化。
spring中在例項化物件的時候用到Strategy模式在SimpleInstantiationStratrgy中有如下程式碼說明了策略模式的使用請了：
public Object instantiate(RootBeanDefinition beanDefinition, String beanName, BeanFactory owner) {
// Don't override the class with CGLIB if no overrides.
if (beanDefinition.getMethodOverrides().isEmpty()) {
Constructor<?> constructorToUse;
synchronized (beanDefinition.constructorArgumentLock) {
constructorToUse = (Constructor<?>) beanDefinition.resolvedConstructorOrFactoryMethod;
if (constructorToUse == null) {
final Class<?> clazz = beanDefinition.getBeanClass();
if (clazz.isInterface()) {
throw new BeanInstantiationException(clazz, "Specified class is an interface");
}
try {
if (System.getSecurityManager() != null) {
constructorToUse = AccessController.doPrivileged(new PrivilegedExceptionAction<Constructor<?>>() {
@Override
public Constructor<?> run() throws Exception {
return clazz.getDeclaredConstructor((Class[]) null);
}
});
}
else {
constructorToUse = clazz.getDeclaredConstructor((Class[]) null);
}
beanDefinition.resolvedConstructorOrFactoryMethod = constructorToUse;
}
catch (Exception ex) {
throw new BeanInstantiationException(clazz, "No default constructor found", ex);
}
}
}
return BeanUtils.instantiateClass(constructorToUse);
}else {
// Must generate CGLIB subclass.
return instantiateWithMethodInjection(beanDefinition, beanName, owner);
}
}第九種：模板方法（Template Method）
定義一個操作中的演算法的骨架，而將一些步驟延遲到子類中。Template Method使得子類可以不改變一個演算法的結構即可重定義該演算法的某些特定步驟。
Template Method模式一般是需要繼承的。這裡想要探討另一種對Template Method的理解。spring中的JdbcTemplate，在用這個類時並不想去繼承這個類，因為這個類的方法太多。但是我們還是想用到JdbcTemplate已有的穩定的、公用的資料庫連線，那麼我們怎麼辦呢？那我們就用回撥物件吧。在這個回撥物件中定義一個操縱JdbcTemplate中變數的方法，我們去實現這個方法，就把變化的東西集中到這裡了。然後我們再傳入這個回撥物件到JdbcTemplate，從而完成了呼叫。這可能是Template Method不需要繼承的另一種實現方式吧。
以下是一個具體的例子： JdbcTemplate中的execute方法 定義一個操作中的演算法的骨架，而將一些步驟延遲到子類中。Template Method使得子類可以不改變一個演算法的結構即可重定義該演算法的某些特定步驟。
Template Method模式一般是需要繼承的。這裡想要探討另一種對Template Method的理解。spring中的JdbcTemplate，在用這個類時並不想去繼承這個類，因為這個類的方法太多，但是我們還是想用到JdbcTemplate已有的穩定的、公用的資料庫連線，那麼我們怎麼辦呢？我們可以把變化的東西抽出來作為一個引數傳入JdbcTemplate的方法中。但是變化的東西是一段程式碼，而且這段程式碼會用到JdbcTemplate中的變數。怎麼辦？那我們就用回撥物件吧。在這個回撥物件中定義一個操縱JdbcTemplate中變數的方法，我們去實現這個方法，就把變化的東西集中到這裡了。然後我們再傳入這個回撥物件到JdbcTemplate，從而完成了呼叫。這可能是Template Method不需要繼承的另一種實現方式吧。
以下是一個具體的例子：
JdbcTemplate中的execute方法
public <T> T execute(StatementCallback<T> action) throws DataAccessException {
Assert.notNull(action, "Callback object must not be null");
Connection con = DataSourceUtils.getConnection(getDataSource());
Statement stmt = null;
try {
Connection conToUse = con;
if (this.nativeJdbcExtractor != null &&
this.nativeJdbcExtractor.isNativeConnectionNecessaryForNativeStatements()) {
conToUse = this.nativeJdbcExtractor.getNativeConnection(con);
}
stmt = conToUse.createStatement();
applyStatementSettings(stmt);
Statement stmtToUse = stmt;
if (this.nativeJdbcExtractor != null) {
stmtToUse = this.nativeJdbcExtractor.getNativeStatement(stmt);
}
T result = action.doInStatement(stmtToUse);
handleWarnings(stmt);
return result;
}
catch (SQLException ex) {
// Release Connection early, to avoid potential connection pool deadlock
// in the case when the exception translator hasn't been initialized yet.
JdbcUtils.closeStatement(stmt);
stmt = null;
DataSourceUtils.releaseConnection(con, getDataSource());
con = null;
throw getExceptionTranslator().translate("StatementCallback", getSql(action), ex);
}
finally {
JdbcUtils.closeStatement(stmt);
DataSourceUtils.releaseConnection(con, getDataSource());
}
}
完結~~~~！！！！