Spring框架的設計理念與設計模式詳解

Spring作為現在最優秀的框架之一，已被廣泛的使用，本文將從另外一個視角試圖剖析出Spring框架的作者設計Spring框架的骨骼架構的設計理念，有那幾個核心元件？為什麼需要這些元件？它們又是如何結合在一起構成Spring的骨骼架構？Spring的AOP特性又是如何利用這些基礎的骨骼架構來工作的？Spring中又使用了那些設計模式來完成它的這種設計的？它的這種 設計理念對對我們以後的軟體設計有何啟示？本文將詳細解答這些問題。

Spring的骨骼架構

Spring總共有十幾個元件，但是真正核心的元件只有幾個，下面是Spring框架的總體架構圖：

圖1.Spring框架的總體架構圖

從上圖中可以看出Spring框架中的核心元件只有三個：Core、Context和Beans。它們構建起了整個Spring的骨骼架構。沒有它們就不可能有AOP、Web等上層的特性功能。下面也將主要從這三個元件入手分析Spring。

Spring的設計理念

前面介紹了Spring的三個核心元件，如果再在它們三個中選出核心的話，那就非Beans元件莫屬了，為何這樣說，其實Spring就是面向Bean的程式設計（BOP,Bean Oriented Programming），Bean在Spring 中才是真正的主角。

Bean在Spring中作用就像Object對OOP的意義一樣，沒有物件的概念就像沒有物件導向程式設計，Spring中沒有Bean也就沒有Spring存在的意義。就像一次演出舞臺都準備好了但是卻沒有演員一樣。為什 麼要Bean這種角色Bean或者為何在Spring如此重要，這由Spring框架的設計目標決定，Spring為何如此流行，我們用Spring的原因是什麼，想想你會發現原來Spring解決了一個非常關鍵的問題他可以讓 你把物件之間的依賴關係轉而用配置檔案來管理，也就是他的依賴注入機制。而這個注入關係在一個叫Ioc容器中管理，那Ioc容器中有又是什麼就是被Bean包裹的物件。Spring正是通過把物件包裝在 Bean中而達到對這些物件管理以及一些列額外操作的目的。

它這種設計策略完全類似於Java實現OOP的設計理念，當然了Java本身的設計要比Spring複雜太多太多，但是都是構建一個資料結構，然後根據這個資料結構設計他的生存環境，並讓它在這個環境中 按照一定的規律在不停的運動，在它們的不停運動中設計一系列與環境或者與其他個體完成資訊交換。這樣想來回過頭想想我們用到的其他框架都是大慨類似的設計理念。

核心元件如何協同工作

前面說Bean是Spring中關鍵因素，那Context和Core又有何作用呢？前面吧Bean比作一場演出中的演員的話，那Context就是這場演出的舞臺背景，而Core應該就是演出的道具了。只有他們在一起才能 具備能演出一場好戲的最基本的條件。當然有最基本的條件還不能使這場演出脫穎而出，還要他表演的節目足夠的精彩，這些節目就是Spring能提供的特色功能了。

我們知道Bean包裝的是Object，而Object必然有資料，如何給這些資料提供生存環境就是Context要解決的問題，對Context來說他就是要發現每個Bean之間的關係，為它們建立這種關係並且要維護好 這種關係。所以Context就是一個Bean關係的集合，這個關係集合又叫Ioc容器，一旦建立起這個Ioc容器後Spring就可以為你工作了。那Core元件又有什麼用武之地呢？其實Core就是發現、建立和維護每 個Bean之間的關係所需要的一些列的工具，從這個角度看來，Core這個元件叫Util更能讓你理解。

它們之間可以用下圖來表示：

圖2.三個元件關係

核心元件詳解

這裡將詳細介紹每個元件內部類的層次關係，以及它們在執行時的時序順序。我們在使用Spring是應該注意的地方。

Bean元件

前面已經說明了Bean元件對Spring的重要性，下面看看Bean這個元件式怎麼設計的。Bean元件在Spring的org.springframework.beans包下。這個包下的所有類主要解決了三件事：Bean的定義、Bean 的建立以及對Bean的解析。對Spring的使用者來說唯一需要關心的就是Bean的建立，其他兩個由Spring在內部幫你完成了，對你來說是透明的。

SpringBean的建立時典型的工廠模式，他的頂級介面是BeanFactory，下圖是這個工廠的繼承層次關係：

圖4.Bean工廠的繼承關係

BeanFactory有三個子類：ListableBeanFactory、HierarchicalBeanFactory和Autowire Capable Bean Factory。但是從上圖中我們可以發現最終的預設實現類是DefaultListableBeanFactory，他實 現了所有的介面。那為何要定義這麼多層次的介面呢？查閱這些介面的原始碼和說明發現，每個介面都有他使用的場合，它主要是為了區分在Spring內部在操作過程中物件的傳遞和轉化過程中，對物件的 資料訪問所做的限制。例如ListableBeanFactory介面表示這些Bean是可列表的，而HierarchicalBeanFactory表示的是這些Bean是有繼承關係的，也就是每個Bean有可能有父Bean。 AutowireCapableBeanFactory介面定義Bean的自動裝配規則。這四個介面共同定義了Bean的集合、Bean之間的關係、以及Bean行為。

Bean的定義主要有BeanDefinition描述，如下圖說明了這些類的層次關係：

圖5.Bean定義的類層次關係圖

Bean的定義就是完整的描述了在Spring的配置檔案中你定義的節點中所有的資訊，包括各種子節點。當Spring成功解析你定義的一個節點後，在Spring的內部他就被轉化 成BeanDefinition物件。以後所有的操作都是對這個物件完成的。

Bean的解析過程非常複雜，功能被分的很細，因為這裡需要被擴充套件的地方很多，必須保證有足夠的靈活性，以應對可能的變化。Bean的解析主要就是對Spring配置檔案的解析。這個解析過程主要通過 下圖中的類完成：

圖6.Bean的解析類

當然還有具體對tag的解析這裡並沒有列出。

Context元件

Context在Spring的org.springframework.context包下，前面已經講解了Context元件在Spring中的作用，他實際上就是給Spring提供一個執行時的環境，用以儲存各個物件的狀態。下面看一下這個 環境是如何構建的。

ApplicationContext是Context的頂級父類，他除了能標識一個應用環境的基本資訊外，他還繼承了五個介面，這五個介面主要是擴充套件了Context的功能。下面是Context的類結構圖：

圖7.Context相關的類結構圖

從上圖中可以看出ApplicationContext繼承了BeanFactory，這也說明了Spring容器中執行的主體物件是Bean，另外ApplicationContext繼承了ResourceLoader介面，使得ApplicationContext可以訪 問到任何外部資源，這將在Core中詳細說明。

ApplicationContext的子類主要包含兩個方面：

ConfigurableApplicationContext表示該Context是可修改的，也就是在構建Context中使用者可以動態新增或修改已有的配置資訊，它下面又有多個子類，其中最經常使用的是可更新的Context，即 AbstractRefreshableApplicationContext類。

WebApplicationContext顧名思義，就是為web準備的Context他可以直接訪問到ServletContext，通常情況下，這個介面使用的少。

再往下分就是按照構建Context的檔案型別，接著就是訪問Context的方式。這樣一級一級構成了完整的Context等級層次。

總體來說ApplicationContext必須要完成以下幾件事：

◆標識一個應用環境

◆利用BeanFactory建立Bean物件

◆儲存物件關係表

◆能夠捕獲各種事件

Context作為Spring的Ioc容器，基本上整合了Spring的大部分功能，或者說是大部分功能的基礎。

Core元件

Core元件作為Spring的核心元件，他其中包含了很多的關鍵類，其中一個重要組成部分就是定義了資源的訪問方式。這種把所有資源都抽象成一個介面的方式很值得在以後的設計中拿來學習。下面就 重要看一下這個部分在Spring的作用。

下圖是Resource相關的類結構圖：

圖8.Resource相關的類結構圖

從上圖可以看出Resource介面封裝了各種可能的資源型別，也就是對使用者來說遮蔽了檔案型別的不同。對資源的提供者來說，如何把資源包裝起來交給其他人用這也是一個問題，我們看到Resource 介面繼承了InputStreamSource介面，這個介面中有個getInputStream方法，返回的是InputStream類。這樣所有的資源都被可以通過InputStream這個類來獲取，所以也遮蔽了資源的提供者。另外還有一 個問題就是載入資源的問題，也就是資源的載入者要統一，從上圖中可以看出這個任務是由ResourceLoader介面完成，他遮蔽了所有的資源載入者的差異，只需要實現這個介面就可以載入所有的資源， 他的預設實現是DefaultResourceLoader。

下面看一下Context和Resource是如何建立關係的？首先看一下他們的類關係圖：

圖9.Context和Resource的類關係圖

從上圖可以看出，Context是把資源的載入、解析和描述工作委託給了ResourcePatternResolver類來完成，他相當於一個接頭人，他把資源的載入、解析和資源的定義整合在一起便於其他元件使用。 Core元件中還有很多類似的方式。

Ioc容器如何工作

前面介紹了Core元件、Bean元件和Context元件的結構與相互關係，下面這裡從使用者角度看一下他們是如何執行的，以及我們如何讓Spring完成各種功能，Spring到底能有那些功能，這些功能是如 何得來的，下面介紹。

如何建立BeanFactory工廠

正如圖2描述的那樣，Ioc容器實際上就是Context元件結合其他兩個元件共同構建了一個Bean關係網，如何構建這個關係網？構建的入口就在AbstractApplicationContext類的refresh方法中。這個方 法的程式碼如下：

清單1.AbstractApplicationContext.refresh

public void refresh() throws BeansException, IllegalStateException {    

    synchronized (this.startupShutdownMonitor) {    

        // Prepare this context for refreshing.    

        prepareRefresh();    

        // Tell the subclass to refresh the internal bean factory.    

        ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();    

        // Prepare the bean factory for use in this context.    

        prepareBeanFactory(beanFactory);    

        try {  

            // Allows post-  processing of the bean factory in context subclasses.  

            postProcessBeanFactory(beanFactory);  

            // Invoke factory processors registered as beans in&  nbsp;the context.  

            invokeBeanFactoryPostProcessors(beanFactory);    

            // Register bean processors that intercept bean crea  tion.  

            registerBeanPostProcessors  (beanFactory);  

            // Initialize message source for this context.    

            initMessageSource();    

            // Initialize event multicaster for this context.    

            initApplicationEventMulticaster();    

            // Initialize other special beans in specific contex  t subclasses.  

            onRefresh();    

            // Check for listener beans and register them.    

            registerListeners();    

            // Instantiate all remaining (non-lazy-init) singletons.    

            finishBeanFactoryInitialization  (beanFactory);  

            // Last step: publish corresponding event.    

            finishRefresh();    

        }  

        catch (BeansException ex) {  

            // Destroy already created singletons to avoid dangl  ing resources.  

            destroyBeans();    

            // Reset 'active' flag.    

            cancelRefresh(ex);    

            // Propagate exception to caller.    

            throw ex;    

        }  

    }  

}

這個方法就是構建整個Ioc容器過程的完整的程式碼，瞭解了裡面的每一行程式碼基本上就瞭解大部分Spring的原理和功能了。

這段程式碼主要包含這樣幾個步驟：

◆構建BeanFactory，以便於產生所需的“演員”

◆註冊可能感興趣的事件

◆建立Bean例項物件

◆觸發被監聽的事件

下面就結合程式碼分析這幾個過程。

第二三句就是在建立和配置BeanFactory。這裡是refresh也就是重新整理配置，前面介紹了Context有可更新的子類，這裡正是實現這個功能，當BeanFactory已存在是就更新，如果沒有就新建立。下面是 更新BeanFactory的方法程式碼：

清單2. AbstractRefreshableApplicationContext. refreshBeanFactory

protected final void refreshBeanFactory() throws BeansException {    

    if (hasBeanFactory()) {    

        destroyBeans();    

        closeBeanFactory();    

    }  

    try {  

        DefaultListableBeanFactory beanFactory = createBeanFactory();  

        beanFactory.setSerializationId(getId());  

        customizeBeanFactory(beanFactory);  

        loadBeanDefinitions(beanFactory);  

        synchronized (this.beanFactoryMonitor) {  

            this.beanFactory = beanFactory;    

        }  

    }  

    catch (IOException ex) {    

        throw new ApplicationContextException(    

                       "I/O error&  nbsp;parsing bean definition source for "  

                       + getDisplayName  (), ex);  

    }  

}

這個方法實現了AbstractApplicationContext的抽象方法refreshBeanFactory，這段程式碼清楚的說明了BeanFactory的建立過程。注意BeanFactory物件的型別的變化，前 面介紹了他有很多子類，在什麼情況下使用不同的子類這非常關鍵。BeanFactory的原始物件是DefaultListableBeanFactory，這個非常關鍵，因為他設計到後面對這個物件的多種操作，下面看一下這個 類的繼承層次類圖：

DefaultListableBeanFactory類繼承關係

圖10.DefaultListableBeanFactory類繼承關係圖

從這個圖中發現除了BeanFactory相關的類外，還發現了與Bean的register相關。這在refreshBeanFactory方法中有一行loadBeanDefinitions(beanFactory)將找到答案，這個方法將開始載入、解析 Bean的定義，也就是把使用者定義的資料結構轉化為Ioc容器中的特定資料結構。

這個過程可以用下面時序圖解釋：

圖11.建立BeanFactory時序圖

Bean的解析和登記流程時序圖如下：

圖12.解析和登記Bean物件時序圖

建立好BeanFactory後，接下去新增一些Spring本身需要的一些工具類，這個操作在AbstractApplicationContext的prepareBeanFactory方法完成。

AbstractApplicationContext中接下來的三行程式碼對Spring的功能擴充套件性起了至關重要的作用。前兩行主要是讓你現在可以對已經構建的BeanFactory的配置做修改，後面一行就是讓你可以對以後再 建立Bean的例項物件時新增一些自定義的操作。所以他們都是擴充套件了Spring的功能，所以我們要學習使用Spring必須對這一部分搞清楚。

其中在invokeBeanFactoryPostProcessors方法中主要是獲取實現BeanFactoryPostProcessor介面的子類。並執行它的postProcessBeanFactory方法，這個方法的宣告如下：

清單3.BeanFactoryPostProcessor.postProcessBeanFactory

void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory)    

    throws BeansException;

它的引數是beanFactory，說明可以對beanFactory做修改，這裡注意這個beanFactory是ConfigurableListableBeanFactory型別的，這也印證了前面介紹的不同BeanFactory所使用的場合不同，這裡 只能是可配置的BeanFactory，防止一些資料被使用者隨意修改。

registerBeanPostProcessors方法也是可以獲取使用者定義的實現了BeanPostProcessor介面的子類，並執行把它們註冊到BeanFactory物件中的beanPostProcessors變數中。BeanPostProcessor中宣告 了兩個方法：postProcessBeforeInitialization、postProcessAfterInitialization分別用於在Bean物件初始化時執行。可以執行使用者自定義的操作。

後面的幾行程式碼是初始化監聽事件和對系統的其他監聽者的註冊，監聽者必須是ApplicationListener的子類。

如何建立Bean例項並構建Bean的關係網

下面就是Bean的例項化程式碼，是從finishBeanFactoryInitialization方法開始的。

清單4.AbstractApplicationContext.finishBeanFactoryInitialization

protected void finishBeanFactoryInitialization(  

        ConfigurableListableBeanFactory beanFactory) {  

    // Stop using the temporary ClassLoader for type matching.    

    beanFactory.setTempClassLoader(null);    

    // Allow for caching all bean definition metadata, not expecting further changes  .  

    beanFactory.freezeConfiguration();    

    // Instantiate all remaining (non-lazy-init) singletons.  

    beanFactory.preInstantiateSingletons();  

}

從上面程式碼中可以發現Bean的例項化是在BeanFactory中發生的。preInstantiateSingletons方法的程式碼如下：

清單5.DefaultListableBeanFactory.preInstantiateSingletons

public void preInstantiateSingletons() throws BeansException {    

    if (this.logger.isInfoEnabled()) {    

        this.logger.info("Pre-  instantiating singletons in " + this);  

    }    

    synchronized (this.beanDefinitionMap) {    

        for   (String beanName : this.beanDefinitionNames) {  

            RootBeanDefinition bd = getMergedLocalBeanDefinition(beanName);    

            if (!bd.isAbstract()   && bd.isSingleton()  

                && !bd.isLazyInit()) {    

                if   (isFactoryBean(beanName)) {  

                    final FactoryBean factory =  

                        (FactoryBean)   getBean(FACTORY_BEAN_PREFIX+ beanName);  

                    boolean isEagerInit;    

                    if (System.getSecurityManager()   != null  

                        &&   ;factory instanceof SmartFactoryBean) {  

                        isEagerInit = AccessController.doPrivileged(    

                          &nb  sp; new PrivilegedAction<Boolean>() {    

                          &nb  sp; public Boolean run() {  

 return ((SmartFactoryBean)   factory).isEagerInit();  

                          &nb  sp; }  

                        }, getAcce  ssControlContext());  

                    }    

                    else {    

                        isEagerInit = factory instanceof SmartFactoryBean    

                          &nb  sp; && ((SmartFactoryBean) factory).isEagerInit();  

                    }    

                    if (isEagerInit) {    

                        getBean  (beanName);  

                    }    

                }    

                else {    

                    getBean(beanName);    

                }    

            }    

        }  

    }  

}

這裡出現了一個非常重要的Bean——FactoryBean，可以說Spring一大半的擴充套件的功能都與這個Bean有關，這是個特殊的Bean他是個工廠Bean，可以產生Bean的Bean，這裡的產生Bean是指 Bean的例項，如果一個類繼承FactoryBean使用者可以自己定義產生例項物件的方法只要實現他的getObject方法。然而在Spring內部這個Bean的例項物件是FactoryBean，通過呼叫這個物件的getObject方 法就能獲取使用者自定義產生的物件，從而為Spring提供了很好的擴充套件性。Spring獲取FactoryBean本身的物件是在前面加上&來完成的。

如何建立Bean的例項物件以及如何構建Bean例項物件之間的關聯關係式Spring中的一個核心關鍵，下面是這個過程的流程圖。

圖13.Bean例項建立流程圖

如果是普通的Bean就直接建立他的例項，是通過呼叫getBean方法。下面是建立Bean例項的時序圖：

圖14.Bean例項建立時序圖

還有一個非常重要的部分就是建立Bean物件例項之間的關係，這也是Spring框架的核心競爭力，何時、如何建立他們之間的關係請看下面的時序圖：

圖15.Bean物件關係建立

Ioc容器的擴充套件點

現在還有一個問題就是如何讓這些Bean物件有一定的擴充套件性，就是可以加入使用者的一些操作。那麼有哪些擴充套件點呢？Spring又是如何呼叫到這些擴充套件點的？

對Spring的Ioc容器來說，主要有這麼幾個。BeanFactoryPostProcessor，BeanPostProcessor。他們分別是在構建BeanFactory和構建Bean物件時呼叫。還有就是InitializingBean和DisposableBean 他們分別是在Bean例項建立和銷燬時被呼叫。使用者可以實現這些介面中定義的方法，Spring就會在適當的時候呼叫他們。還有一個是FactoryBean他是個特殊的Bean，這個Bean可以被使用者更多的控制。

這些擴充套件點通常也是我們使用Spring來完成我們特定任務的地方，如何精通Spring就看你有沒有掌握好Spring有哪些擴充套件點，並且如何使用他們，要知道如何使用他們就必須瞭解他們內在的機理。可 以用下面一個比喻來解釋。

我們把Ioc容器比作一個箱子，這個箱子裡有若干個球的模子，可以用這些模子來造很多種不同的球，還有一個造這些球模的機器，這個機器可以產生球模。那麼他們的對應關係就是BeanFactory就是 那個造球模的機器，球模就是Bean，而球模造出來的球就是Bean的例項。那前面所說的幾個擴充套件點又在什麼地方呢？BeanFactoryPostProcessor對應到當造球模被造出來時，你將有機會可以對其做出設 當的修正，也就是他可以幫你修改球模。而InitializingBean和DisposableBean是在球模造球的開始和結束階段，你可以完成一些預備和掃尾工作。BeanPostProcessor就可以讓你對球模造出來的球做出 適當的修正。最後還有一個FactoryBean，它可是一個神奇的球模。這個球模不是預先就定型了，而是由你來給他確定它的形狀，既然你可以確定這個球模型的形狀，當然他造出來的球肯定就是你想要的 球了，這樣在這個箱子里尼可以發現所有你想要的球

Ioc容器如何為我所用

前面的介紹了Spring容器的構建過程，那Spring能為我們做什麼，Spring的Ioc容器又能做什麼呢？我們使用Spring必須要首先構建Ioc容器，沒有它Spring無法工作，ApplicatonContext.xml就是Ioc 容器的預設配置檔案，Spring的所有特性功能都是基於這個Ioc容器工作的，比如後面要介紹的AOP。

Ioc它實際上就是為你構建了一個魔方，Spring為你搭好了骨骼架構，這個魔方到底能變出什麼好的東西出來，這必須要有你的參與。那我們怎麼參與？這就是前面說的要了解Spring中那有些擴充套件點 ，我們通過實現那些擴充套件點來改變Spring的通用行為。至於如何實現擴充套件點來得到我們想要的個性結果，Spring中有很多例子，其中AOP的實現就是Spring本身實現了其擴充套件點來達到了它想要的特性功能 ，可以拿來參考。

Spring中AOP特性詳解

動態代理的實現原理

要了解Spring的AOP就必須先了解的動態代理的原理，因為AOP就是基於動態代理實現的。動態代理還要從JDK本身說起。

在Jdk的java.lang.reflect包下有個Proxy類，它正是構造代理類的入口。這個類的結構入下：

圖16.Proxy類結構

從上圖發現最後面四個是公有方法。而最後一個方法newProxyInstance就是建立代理物件的方法。這個方法的原始碼如下：

清單6.Proxy.newProxyInstance

public static Object newProxyInstance(ClassLoader loader,    

    Class>  [] interfaces,  

    InvocationHandler h)    

    throws IllegalArgumentException {    

        if (h == null) {    

        throw new NullPointerException();    

    }  

    Class cl = getProxyClass  (loader, interfaces);  

    try {    

        Constructor cons = cl.getConstructor(constructorParams);    

        return (Object) cons.newInstance(new Object[]   { h });  

    } catch (NoSuchMethodException e) {    

        throw new InternalError(e.toString());    

    } catch (IllegalAccessException e) {    

        throw new InternalError(e.toString());    

    } catch (InstantiationException e) {    

        throw new InternalError(e.toString());    

    } catch (InvocationTargetException e) {    

        throw new InternalError(e.toString());    

    }  

}    !

這個方法需要三個引數：ClassLoader，用於載入代理類的Loader類，通常這個Loader和被代理的類是同一個Loader類。Interfaces，是要被代理的那些那些介面。InvocationHandler，就是用於執行 除了被代理介面中方法之外的使用者自定義的操作，他也是使用者需要代理的最終目的。使用者呼叫目標方法都被代理到InvocationHandler類中定義的唯一方法invoke中。這在後面再詳解。

下面還是看看Proxy如何產生代理類的過程，他構造出來的代理類到底是什麼樣子？下面揭曉啦。

圖17.建立代理物件時序圖

其實從上圖中可以發現正在構造代理類的是在ProxyGenerator的generateProxyClass的方法中。ProxyGenerator類在sun.misc包下，感興趣的話可以看看他的原始碼。

假如有這樣一個介面，如下：

清單7.SimpleProxy類

public interface SimpleProxy {  

    public void simpleMethod1();    

    public void simpleMethod2();  

}

代理來生成的類結構如下：

清單 8.$Proxy2類

public class $Proxy2 extends java.lang.reflect.Proxy implements SimpleProxy{    

    java.lang.reflect.Method m0;    

    java.lang.reflect.Method m1;  

    java.lang.reflect.Method m2;  

    java.lang.reflect.Method m3;  

    java.lang.reflect.Method m4;  

    int hashCode();  

    boolean equals(java.lang.Object);  

    java.lang.String toString();  

    void simpleMethod1();  

    void simpleMethod2();  

}

這個類中的方法裡面將會是呼叫InvocationHandler的invoke方法，而每個方法也將對應一個屬性變數，這個屬性變數m也將傳給invoke方法中的Method引數。整個代理就是這樣實現的。

SpringAOP如何實現

從前面代理的原理我們知道，代理的目的是呼叫目標方法時我們可以轉而執行InvocationHandler類的invoke方法，所以如何在InvocationHandler上做文章就是Spring實現Aop的關鍵所在。

Spring的Aop實現是遵守Aop聯盟的約定。同時Spring又擴充套件了它，增加了如Pointcut、Advisor等一些介面使得更加靈活。

下面是Jdk動態代理的類圖：

圖18.Jdk動態代理的類圖

上圖清楚的顯示了Spring引用了Aop Alliance定義的介面。姑且不討論Spring如何擴充套件Aop Alliance，先看看Spring如何實現代理類的，要實現代理類在Spring的配置檔案中通常是這樣定一個Bean的 ，如下：

清單9.配置代理類Bean

<bean id="testBeanSingleton" 

    class="org.springframework.aop.framework.ProxyFactoryBean"> 

    <property name="proxyInterfaces"> 

        <value> 

            org.springframework.aop.framework.PrototypeTargetTests$TestBean    

        value> 

    property> 

    <property name="target"><ref local="testBeanTarget">ref> property> 

    <property name="singleton"><value>truevalue>property> 

    <property name="interceptorNames"> 

        <list> 

            <value>testInterceptorvalue> 

            <value>testInterceptor2value> 

        list> 

    property> 

bean>

配置上看到要設定被代理的介面，和介面的實現類也就是目標類，以及攔截器也就在執行目標方法之前被呼叫，這裡Spring中定義的各種各樣的攔截器，可以選擇使用。

下面看看Spring如何完成了代理以及是如何呼叫攔截器的。

前面提到Spring Aop也是實現其自身的擴充套件點來完成這個特性的，從這個代理類可以看出它正是繼承了Factory Bean的ProxyFactoryBean，FactoryBean之所以特別就在它可以讓你自定義物件的建立 方法。當然代理物件要通過Proxy類來動態生成。

下面是Spring建立的代理物件的時序圖：

圖19.Spring代理物件的產生

Spring建立了代理物件後，當你呼叫目標物件上的方法時，將都會被代理到InvocationHandler類的invoke方法中執行，這在前面已經解釋。在這裡JdkDynamicAopProxy類實現了InvocationHandler接 口。

下面再看看Spring是如何呼叫攔截器的，下面是這個過程的時序圖：

圖20.Spring呼叫攔截器

以上所說的都是Jdk動態代理，Spring還支援一種CGLIB類代理，感興趣自己看吧。

Spring中設計模式分析

Spring中使用的設計模式也很多，比如工廠模式、單例模式、模版模式等，在《Webx框架的系統架構與設計模式》、《Tomcat的系統架構與模式設計分析》已經有介紹，這裡就不贅述了。這裡主要介 紹代理模式和策略模式。

代理模式

代理模式原理

代理模式就是給某一個物件建立一個代理物件，而由這個代理物件控制對原物件的引用，而建立這個代理物件就是可以在呼叫原物件是可以增加一些額外的操作。下面是代理模式的結構：

圖21.代理模式的結構

Subject：抽象主題，它是代理物件的真實物件要實現的介面，當然這可以是多個介面組成。

ProxySubject：代理類除了實現抽象主題定義的介面外，還必須持有所代理物件的引用

RealSubject：被代理的類，是目標物件。

Spring中如何實現代理模式

Spring Aop中Jdk動態代理就是利用代理模式技術實現的。在Spring中除了實現被代理物件的介面外，還會有org.springframework.aop.SpringProxy和org.springframework.aop.framework.Advised 兩個介面。Spring中使用代理模式的結構圖如下：

圖22.Spring中使用代理模式的結構圖

$Proxy就是建立的代理物件，而Subject是抽象主題，代理物件是通過InvocationHandler來持有對目標物件的引用的。

Spring中一個真實的代理物件結構如下：

清單10代理物件$Proxy4

public class $Proxy4 extends java.lang.reflect.Proxy implements    

    org.springframework.aop.framework.PrototypeTargetTests$TestBean    

        org.springframework.aop.SpringProxy    

        org.springframework.aop.framework.Advised    

{  

    java.lang.reflect.Method m16;  

    java.lang.reflect.Method m9;  

    java.lang.reflect.Method m25;  

    java.lang.reflect.Method m5;  

    java.lang.reflect.Method m2;  

    java.lang.reflect.Method m23;  

    java.lang.reflect.Method m18;  

    java.lang.reflect.Method m26;  

    java.lang.reflect.Method m6;  

    java.lang.reflect.Method m28;  

    java.lang.reflect.Method m14;  

    java.lang.reflect.Method m12;  

    java.lang.reflect.Method m27;  

    java.lang.reflect.Method m11;  

    java.lang.reflect.Method m22;  

    java.lang.reflect.Method m3;  

    java.lang.reflect.Method m8;  

    java.lang.reflect.Method m4;  

    java.lang.reflect.Method m19;  

    java.lang.reflect.Method m7;  

    java.lang.reflect.Method m15;  

    java.lang.reflect.Method m20;  

    java.lang.reflect.Method m10;  

    java.lang.reflect.Method m1;  

    java.lang.reflect.Method m17;  

    java.lang.reflect.Method m21;  

    java.lang.reflect.Method m0;  

    java.lang.reflect.Method m13;  

    java.lang.reflect.Method m24;  

    int hashCode();  

    int indexOf(org.springframework.aop.Advisor);  

    int indexOf(org.aopalliance.aop.Advice);  

    boolean equals(java.lang.Object);  

    java.lang.String toString();  

    void sayhello();  

    void doSomething();  

    void doSomething2();  

    java.lang.Class getProxiedInterfaces();  

    java.lang.Class getTargetClass();  

    boolean isProxyTargetClass();  

    org.springframework.aop.Advisor; getAdvisors();  

    void addAdvisor(int, org.springframework.aop.Advisor)  

               throws org.springframework.aop.framework.AopConfigException;    

    void addAdvisor(org.springframework.aop.Advisor)    

               throws org.springframework.aop.framework.AopConfigException;    

    void setTargetSource(org.springframework.aop.TargetSource);    

    org.springframework.aop.TargetSource getTargetSource();    

    void setPreFiltered(boolean);  

    boolean isPreFiltered();  

    boolean isInterfaceProxied(java.lang.Class);  

    boolean removeAdvisor(org.springframework.aop.Advisor);  

    void removeAdvisor(int)throws org.springframework.aop.framework.AopConfigException;    

    boolean replaceAdvisor(org.springframework.aop.Advisor,    

               org.springframework.aop.Advisor)    

               throws org.springframework.aop.framework.AopConfigException;    

    void addAdvice(org.aopalliance.aop.Advice)    

               throws org.springframework.aop.framework.AopConfigException;    

    void addAdvice(int, org.aopalliance.aop.Advice)    

               throws org.springframework.aop.framework.AopConfigException;    

    boolean removeAdvice(org.aopalliance.aop.Advice);    

    java.lang.String toProxyConfigString();    

    boolean isFrozen();  

    void setExposeProxy(boolean);  

    boolean isExposeProxy();  

}

策略模式

策略模式原理

策略模式顧名思義就是做某事的策略，這在程式設計上通常是指完成某個操作可能有多種方法，這些方法各有千秋，可能有不同的適應的場合，然而這些操作方法都有可能用到。各一個操作方法都當作一 個實現策略，使用者可能根據需要選擇合適的策略。

下面是策略模式的結構：

圖23.策略模式的結構

Context：使用不同策略的環境，它可以根據自身的條件選擇不同的策略實現類來完成所要的操作。它持有一個策略例項的引用。建立具體策略物件的方法也可以由他完成。

◆Strategy：抽象策略，定義每個策略都要實現的策略方法

◆ConcreteStrategy：具體策略實現類，實現抽象策略中定義的策略方法

◆Spring中策略模式的實現

◆Spring中策略模式使用有多個地方，如Bean定義物件的建立以及代理物件的建立等。這裡主要看一下代理物件建立的策略模式的實現。

前面已經瞭解Spring的代理方式有兩個Jdk動態代理和CGLIB代理。這兩個代理方式的使用正是使用了策略模式。它的結構圖如下所示：

圖24.Spring中策略模式結構圖

在上面結構圖中與標準的策略模式結構稍微有點不同，這裡抽象策略是AopProxy介面，Cglib2AopProxy和JdkDynamicAopProxy分別代表兩種策略的實現方式，ProxyFactoryBean就是代表Context角色 ，它根據條件選擇使用Jdk代理方式還是CGLIB方式，而另外三個類主要是來負責建立具體策略物件，ProxyFactoryBean是通過依賴的方法來關聯具體策略物件的，它是通過呼叫策略物件的getProxy (ClassLoaderclassLoader)方法來完成操作。

總結

本文通過從Spring的幾個核心元件入手，試圖找出構建Spring框架的骨骼架構，進而分析Spring在設計的一些設計理念，是否從中找出一些好的設計思想，對我們以後程式設計能提供一些思路。接著 再詳細分析了Spring中是如何實現這些理念的，以及在設計模式上是如何使用的。

通過分析Spring給我一個很大的啟示就是其這套設計理念其實對我們有很強的借鑑意義，它通過抽象複雜多變的物件，進一步做規範，然後根據它定義的這套規範設計出一個容器，容器中構建它們的 複雜關係，其實現在有很多情況都可以用這種類似的處理方法。

雖然我很想把我對Spring的想法完全闡述清楚，但是所謂“書不盡言，言不盡意。”，有什麼不對或者不清楚的地方大家還是看看其原始碼吧。