Spring中的用到的設計模式大全
spring中常用的設計模式達到九種，我們舉例說明：
第一種：簡單工廠
又叫做靜態工廠方法（StaticFactory Method）模式，但不屬於23種GOF設計模式之一。
簡單工廠模式的實質是由一個工廠類根據傳入的參數，動態決定應該創建哪一個產品類。
spring中的BeanFactory就是簡單工廠模式的體現，根據傳入一個唯一的標識來獲得bean對象，但是否是在傳入參數后創建還是傳入參數前創建這個要根據具體情況來定。如下配置，就是在 HelloItxxz 類中創建一個 itxxzBean。
第二種：工廠方法（Factory Method）
//調用getBean()時,返回隨機數.如果沒有指定factory-method,會返回StaticFactoryBean的實例,即返回工廠Bean的實例 XmlBeanFactory factory = new XmlBeanFactory(new ClassPathResource("config.xml")); System.out.println("我是IT學習者創建的實例:"+factory.getBean("random").toString());
第三種：單例模式（Singleton）
保證一個類僅有一個實例，並提供一個訪問它的全局訪問點。
spring中的單例模式完成了后半句話，即提供了全局的訪問點BeanFactory。但沒有從構造器級別去控制單例，這是因為spring管理的是是任意的java對象。
核心提示點：Spring下默認的bean均為singleton，可以通過singleton=“true|false” 或者 scope=“？”來指定
第四種：適配器（Adapter）
在Spring的Aop中，使用的Advice（通知）來增強被代理類的功能。Spring實現這一AOP功能的原理就使用代理模式（1、JDK動態代理。2、CGLib字節碼生成技術代理。）對類進行方法級別的切面增強，即，生成被代理類的代理類， 並在代理類的方法前，設置攔截器，通過執行攔截器重的內容增強了代理方法的功能，實現的面向切面編程。
第五種：包裝器（Decorator）
在我們的項目中遇到這樣一個問題：我們的項目需要連接多個數據庫，而且不同的客戶在每次訪問中根據需要會去訪問不同的數據庫。我們以往在spring和hibernate框架中總是配置一個數據源，因而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等。然后sessionFactory根據客戶的每次請求，將dataSource屬性設置成不同的數據源，以到達切換數據源的目的。
spring中用到的包裝器模式在類名上有兩種表現：一種是類名中含有Wrapper，另一種是類名中含有Decorator。基本上都是動態地給一個對象添加一些額外的職責。
第六種：代理（Proxy）
為其他對象提供一種代理以控制對這個對象的訪問。 從結構上來看和Decorator模式類似，但Proxy是控制，更像是一種對功能的限制，而Decorator是增加職責。
spring的Proxy模式在aop中有體現，比如JdkDynamicAopProxy和Cglib2AopProxy。
第七種：觀察者（Observer）
定義對象間的一種一對多的依賴關系，當一個對象的狀態發生改變時，所有依賴於它的對象都得到通知並被自動更新。
spring中Observer模式常用的地方是listener的實現。如ApplicationListener。
第八種：策略（Strategy）
定義一系列的算法，把它們一個個封裝起來，並且使它們可相互替換。本模式使得算法可獨立於使用它的客戶而變化。
spring中在實例化對象的時候用到Strategy模式
在SimpleInstantiationStrategy中有如下代碼說明了策略模式的使用情況： 
第九種：模板方法（Template Method）
定義一個操作中的算法的骨架，而將一些步驟延遲到子類中。Template Method使得子類可以不改變一個算法的結構即可重定義該算法的某些特定步驟。
Template Method模式一般是需要繼承的。這里想要探討另一種對Template Method的理解。spring中的JdbcTemplate，在用這個類時並不想去繼承這個類，因為這個類的方法太多，但是我們還是想用到JdbcTemplate已有的穩定的、公用的數據庫連接，那么我們怎么辦呢？我們可以把變化的東西抽出來作為一個參數傳入JdbcTemplate的方法中。但是變化的東西是一段代碼，而且這段代碼會用到JdbcTemplate中的變量。怎么辦？那我們就用回調對象吧。在這個回調對象中定義一個操縱JdbcTemplate中變量的方法，我們去實現這個方法，就把變化的東西集中到這里了。然后我們再傳入這個回調對象到JdbcTemplate，從而完成了調用。這可能是Template Method不需要繼承的另一種實現方式吧。
以下是一個具體的例子：
JdbcTemplate中的execute方法 
JdbcTemplate執行execute方法 
mybatis中使用到的設計模式
Mybatis中使用到了哪些設計模式呢？下面就簡單的來介紹下：
1.構造者模式：
構造者模式是在mybatis初始化mapper映射文件的過程中，為<cache>節點創建Cache對象的方式就是構造者模式。其中CacheBilder為建造者角色，Cache對象是產品角色，可以看CacheBuilder的源碼來理解：
// 該類就是構造者
public class CacheBuilder {
// 這幾個屬性就是為生成產品對象需要的字段 private String id; private Class<? extends Cache> implementation; private List<Class<? extends Cache>> decorators; private Integer size; private Long clearInterval; private boolean readWrite; private Properties properties; public CacheBuilder(String id) { this.id = id; this.decorators = new ArrayList<Class<? extends Cache>>(); } // 以下這幾個方法就是構造者在生成產品對象時，需要使用到的幾個具體模塊方法。可以根據這幾個方法的不同組合，生成不同的Cache對象 public CacheBuilder implementation(Class<? extends Cache> implementation) { this.implementation = implementation; return this; } public CacheBuilder addDecorator(Class<? extends Cache> decorator) { if (decorator != null) { this.decorators.add(decorator); } return this; } public CacheBuilder size(Integer size) { this.size = size; return this; } public CacheBuilder clearInterval(Long clearInterval) { this.clearInterval = clearInterval; return this; } public CacheBuilder readWrite(boolean readWrite) { this.readWrite = readWrite; return this; } public CacheBuilder properties(Properties properties) { this.properties = properties; return this; } // 這個方法就是構造者生成產品的具體方法 返回的Cahce對象就是產品角色 public Cache build() { setDefaultImplementations(); Cache cache = newBaseCacheInstance(implementation, id); setCacheProperties(cache); if (PerpetualCache.class.equals(cache.getClass())) { // issue #352, do not apply decorators to custom caches for (Class<? extends Cache> decorator : decorators) { cache = newCacheDecoratorInstance(decorator, cache); setCacheProperties(cache); } cache = setStandardDecorators(cache); } return cache; } }
2 裝飾器模式
Cache接口的實現有多個，但是大部分都是裝飾器，只有PerpetualCache提供了Cache接口的基本實現，其他的裝飾器都是在PerpetualCache的基礎上提供了一些額外的功能，通過各種組合后滿足一個特定的需求。如圖：
先看下被裝飾者PerpetualCache的源碼部分：
private String id; // cache對象的唯一標識
// 底層使用HashMap來保存緩存信息
private Map<Object, Object> cache = new HashMap<Object, Object>();
public PerpetualCache(String id) {
this.id = id;
}
public String getId() {
return id;
}
public int getSize() {
return cache.size();
}
public void putObject(Object key, Object value) {
cache.put(key, value);
}
然后再看LruCache這個裝飾器：
private final Cache delegate; // 被裝飾的底層cache對象
private Map<Object, Object> keyMap; // LinkedHashMap 用於記錄key最近的使用情況
private Object eldestKey; // 記錄最少被使用的緩存項的key
public LruCache(Cache delegate) {
this.delegate = delegate;
setSize(1024);
}
3 工廠方法模式
mybatis中DataSource的創建使用了工廠方法模式，那么有哪些類在該模式中扮演了哪些角色呢？
工廠接口（Factory）：DataSourceFactory扮演工廠接口角色
具體工廠類（ConcreteFactory）：UnpooledDataSourceFactory和PooledDataSourceFactory
產品接口角色（Product）：java.sql.DataSource
具體產品類角色（ConcreteFactory）：UnpooledDataSource和PooledDataSource
可以用一張圖來表示這些關系和角色：
