Spring中的用到的設計模式

應該說設計模式是咱們在寫代碼時候的一種被認可的較好的模式。好的設計模式就像是給代碼造了一個很好的骨架，在這個骨架裏，你能夠知道心在哪裏，肺在哪裏，由於大多數人都認識這樣的骨架，就有了很好的傳播性。這是從易讀和易傳播來感知設計模式的好處。固然設計模式自己更重要的是設計原則的一種實現，好比開閉原則，依賴倒置原則，這些是在代碼的修改和擴展上說事。說到底就是人類和代碼發生關係的四種場合：閱讀，修改，增長，刪除。讓每一種場合都比較舒服的話，就須要用設計模式。

下面來簡單列舉Spring中的設計模式：

1. 簡單工廠

又叫作靜態工廠方法（StaticFactory Method）模式，但不屬於23種GOF設計模式之一。

簡單工廠模式的實質是由一個工廠類根據傳入的參數，動態決定應該建立哪個產品類。

Spring中的BeanFactory就是簡單工廠模式的體現，根據傳入一個惟一的標識來得到Bean對象，可是否是在傳入參數後建立仍是傳入參數前建立這個要根據具體狀況來定。

以下配置，就是在 HelloItxxz 類中建立一個 itxxzBean。

<beans>

    <bean id="singletonBean" class="com.itxxz.HelloItxxz">

        <constructor-arg>

            <value>Hello! 這是singletonBean!value>

        </constructor-arg>

   </ bean>

 

    <bean id="itxxzBean" class="com.itxxz.HelloItxxz"

        singleton="false">

        <constructor-arg>

            <value>Hello! 這是itxxzBean! value>

        </constructor-arg>

    </bean>

 

</beans>

2. 工廠方法（Factory Method）

定義一個用於建立對象的接口，讓子類決定實例化哪個類。Factory Method使一個類的實例化延遲到其子類。

Spring中的FactoryBean就是典型的工廠方法模式。

一般由應用程序直接使用new建立新的對象，爲了將對象的建立和使用相分離，採用工廠模式,即應用程序將對象的建立及初始化職責交給工廠對象。

通常狀況下,應用程序有本身的工廠對象來建立bean.若是將應用程序本身的工廠對象交給Spring管理,那麼Spring管理的就不是普通的bean,而是工廠Bean。

螃蟹就以工廠方法中的靜態方法爲例講解一下：

import java.util.Random;

public class StaticFactoryBean {

      public static Integer createRandom() {

           return new Integer(new Random().nextInt());

       }

}

建一個config.xm配置文件，將其歸入Spring容器來管理,須要經過factory-method指定靜態方法名稱

<bean id="random"

class="example.chapter3.StaticFactoryBean" factory-method="createRandom" //createRandom方法必須是static的,才能找到 scope="prototype"

/>

測試:

public static void main(String[] args) {
      //調用getBean()時,返回隨機數.若是沒有指定factory-method,會返回StaticFactoryBean的實例,即返回工廠Bean的實例       XmlBeanFactory factory = new XmlBeanFactory(new ClassPathResource("config.xml"));       System.out.println("我是IT學習者建立的實例:"+factory.getBean("random").toString());

}

3. 單例（Singleton）

保證一個類僅有一個實例，並提供一個訪問它的全局訪問點。

Spring中的單例模式完成了後半句話，即提供了全局的訪問點BeanFactory。但沒有從構造器級別去控制單例，這是由於Spring管理的是是任意的Java對象。

核心提示點：Spring下默認的bean均爲singleton，能夠經過singleton=「true|false」 或者 scope=「？」來指定

4. 適配器（Adapter）

將一個類的接口轉換成客戶但願的另一個接口。Adapter模式使得本來因爲接口不兼容而不能一塊兒工做的那些類能夠一塊兒工做。

Spring中在對於AOP的處理中有Adapter模式的例子

在Spring的Aop中，使用的Advice（通知）來加強被代理類的功能。Spring實現這一AOP功能的原理就使用代理模式（一、JDK動態代理。二、CGLib字節碼生成技術代理。）對類進行方法級別的切面加強，即，生成被代理類的代理類， 並在代理類的方法前，設置攔截器，經過執行攔截器重的內容加強了代理方法的功能，實現的面向切面編程。

Adapter類接口：Target

public interface AdvisorAdapter {

 

boolean supportsAdvice(Advice advice);

 

      MethodInterceptor getInterceptor(Advisor advisor);

 

}  MethodBeforeAdviceAdapter類，Adapter

class MethodBeforeAdviceAdapter implements AdvisorAdapter, Serializable {

 

      public boolean supportsAdvice(Advice advice) {

            return (advice instanceof MethodBeforeAdvice);

      }

 

      public MethodInterceptor getInterceptor(Advisor advisor) {

            MethodBeforeAdvice advice = (MethodBeforeAdvice) advisor.getAdvice();

      return new MethodBeforeAdviceInterceptor(advice);

      }

 

}

 

5.包裝器（Decorator）

動態地給一個對象添加一些額外的職責。就增長功能來講，Decorator模式相比生成子類更爲靈活。

Spring中用到的包裝器模式在類名上有兩種表現：一種是類名中含有Wrapper，另外一種是類名中含有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屬性設置成不一樣的數據源，以到達切換數據源的目的。

 

 

6. 代理（Proxy）

爲其餘對象提供一種代理以控制對這個對象的訪問。

從結構上來看和Decorator模式相似，但Proxy是控制，更像是一種對功能的限制，而Decorator是增長職責。

Spring的Proxy模式在aop中有體現，好比JdkDynamicAopProxy和Cglib2AopProxy。

 

7.觀察者（Observer）

定義對象間的一種一對多的依賴關係，當一個對象的狀態發生改變時，全部依賴於它的對象都獲得通知並被自動更新。

Spring中Observer模式經常使用的地方是listener的實現。如ApplicationListener。

8. 策略（Strategy）

定義一系列的算法，把它們一個個封裝起來，而且使它們可相互替換。本模式使得算法可獨立於使用它的客戶而變化。

Spring中在實例化對象的時候用到Strategy模式，見以下圖：

在SimpleInstantiationStrategy中有以下代碼說明了策略模式的使用狀況：

還有 ，第一個地方，加載資源文件的方式，使用了不一樣的方法，好比：ClassPathResourece，FileSystemResource，ServletContextResource，UrlResource但他們都有共同的藉口Resource；

第二個地方就是在Aop的實現中，採用了兩種不一樣的方式，JDK動態代理和CGLIB代理；

第三個地方就是Spring的事務管理，PlatformTransactionManager表明事務管理接口，可是它不知道底層如何管理事務，它只要求事務管理

提供開始事務(getTransaction(),commit(),rollback()三個方法，可是如何實現則交給具體實現類來完成--不一樣的實現類表明不一樣的事務管理策略。

通常來講，spring事務管理下面主要針對

1) JDBC(org.springframework.jdbc.datasource.DataSourceTransactionManager),

2) Hibernate (org.springframework.orm.hibernate3.HibernateTransactionManager)，

3) JTA (org.springframework.transaction.jta.JtaTransactionManager)和

4) JPA(org.springframework.orm.jpa.JpaTransactionManager)

四種具體的底層事務控制來包裝的。

9.模板方法（Template Method）

定義一個操做中的算法的骨架，而將一些步驟延遲到子類中。Template Method使得子類能夠不改變一個算法的結構便可重定義該算法的某些特定步驟。Template Method模式通常是須要繼承的。這裏想要探討另外一種對Template Method的理解。Spring中的JdbcTemplate，在用這個類時並不想去繼承這個類，由於這個類的方法太多，可是咱們仍是想用到JdbcTemplate已有的穩定的、公用的數據庫鏈接，那麼咱們怎麼辦呢？咱們能夠把變化的東西抽出來做爲一個參數傳入JdbcTemplate的方法中。可是變化的東西是一段代碼，並且這段代碼會用到JdbcTemplate中的變量。怎麼辦？那咱們就用回調對象吧。在這個回調對象中定義一個操縱JdbcTemplate中變量的方法，咱們去實現這個方法，就把變化的東西集中到這裏了。而後咱們再傳入這個回調對象到JdbcTemplate，從而完成了調用。這多是Template Method不須要繼承的另外一種實現方式吧。

如下是一個具體的例子：

JdbcTemplate中的execute方法：

JdbcTemplate執行execute方法：