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功能的原理就使用代理模式（一、JDK動態代理。二、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());
	}
}

 

完結~~~~！！！！