Spring框架涉及到的設計模式：
Spring用到了很多的設計模式，其中最重要的兩個設計模式是：
1、 工廠模式
a) Spring容器就是實例化和管理Bean的工廠 工廠模式可以將Java對象的調用者從被調用者的實現邏輯中分離出來。調用者只關心被調用者必須滿足的某種規則，這裡的規則我們可以看作是接口，而不必關心實例的具體實現過程，具體的實現過程，有Bean工廠來完成。
2、 單態模式【單例模式】
a) Spring默認將所有的Bean設置成 單例模式，即對所有的相同id的Bean的請求，都將返回同一個共享的Bean實例。這樣就可以大大降低Java創建對象和銷燬時的系統開銷。使用Spring將Bean設置稱為單例行為，則無需自己完成單例模式。
回顧：單態模式【單例模式】
單態模式限制了類的實例的創建，採用這種設計模式設計的類，可以保證僅有一個實例，並提供訪問該實例的全局訪問點。
J2EE應用了大量的組件，都需要保證一個類只有一個實例，比如：數據塊引擎的訪問點只能有一個。而更多的時候，是為了提高性能。應用程序應該儘量減少Java對象的創建和銷燬時的開銷。那麼使用單例模式可以避免Java頻繁的實例化。讓相同的實例全部共享同一個內存區，為了防止單態模式類的實例頻繁實例化，應該將類的構造函數設置為私有的，這樣只能通過靜態方法獲取類的實例，而靜態方法則需要保證每次返回的實例都是同一個，那麼就需要將該類的實例設置成類的屬性，該屬性需要在靜態的方法裡面訪問，因此該屬性還必須是靜態的屬性。說了這麼多，見如下代碼：
public class Person {
//私有Person類型的屬性
private static Person per;
//私有構造
private Person(){}
//返回該類的實例的靜態方法
public static Person CreateObject(){
if (per==null) {
per=new Person();
}
return per;
}
}
public static void main(String[] args) {
Person p_one=Person.CreateObject();
Person p_two=Person.CreateObject();
}
回顧：工廠模式
工廠模式：根據調用數據返回某個類的一個實例，此類可能是多個類的某一個實例，通常這些類滿足共同的接口或者父類，而調用者不用關心工廠裡有多少個類，它只關心生產出來的實例是否滿足某種規範。這個模式提供清晰的角色劃分，降低程序耦合。
在工廠模式中，接口生產的全部實例通常實現相同的接口或者繼承同一個類，接口裡面全部實現共同擁有的方法，但是這些方法在不同的實現類中，他們的實現方式不盡相同，程序的調用者不關心具體是如何實現的，從而降低了系統的異構代價。
見示例：
Spring的實現
前面我們回顧了單例模式和工廠模式的實現，下面我們看一下Spring是如何實現這兩種模式的。
這裡我們無需修改接口的實現類，也就是說無需修改接口及其實現類，但是因為Spring是用工廠模式實現的，所以我們就不用寫什麼工廠類了，就交給Spring來實現了。Spring通過配置文件，就可以管理所有的bean，而這些bean就是Spring工廠能產生的實例，因此，首先我們在Spring配置文件中對兩個實例進行配置。
Spring核心機制
前面說到Spring的核心機制就是依賴注入，現在我們就來看看什麼是依賴注入：
控制反轉和依賴注入
當某個角色需要另一個角色協助的時候，在傳統的程序設計過程中，通常由調用者創建被調用者的實例。但是在Spring裡面，創建被調用者的工作不再由調用者來完成，因此被稱為控制反轉，創建被調用者實例的工作通常由Spring容器來完成，然後注入調用者，因此也稱之為依賴注入。
依賴：
兩個元素中一個定義發生改變則會引起另一個元素髮生改變，則稱這兩個元素之間存在依賴關係。
一個類要發消息給另一個類，一個類將另一個類作為數據的一部分，一個類操作另一個類作為其參數。這些情況都是一個類依賴另一個類。類與類之間的依賴關係增加類程序的複雜程度，我們在開發一個類的時候，還要考慮相關的其他類的屬性和行為。
早期的時候：程序只是用來計算，沒有複雜的邏輯，面向過程就可以搞定類，後來程序規模越來越大，需要處理的邏輯就越來越複雜，類與類之間的關係也就越來越複雜，面向對象就有必要了，當我們用一個程序模擬一個櫃子組裝的過程的時候，我們把擋板，框架，釘子等櫃子的組件作為不同的對象，而當我們組裝的時候，主要把這些對象組合在一起就可以形成一個櫃子。這裡我們可以看到面向對象的優點。
我們可以看一下我們的電腦，電腦，主板是由主板廠商生產的，CPU是CPU廠商生產的，硬盤是由硬盤廠商生產的等等，那麼硬盤的廠商設計產品的時候，需不需要CPU支持什麼指令集？主板採用什麼樣的芯片組呢？當然不需要，它只知道別人會留好接口，他也只會按照行業標準給別人留好接口就可以了。電腦的各個組件之間當然是有依賴關係的，但是由於明確定義了他們之間的接口，各組件實現的時候，完全不用考慮這些組件之間的依賴關係，從而使得我們獲得了構建複雜系統的能力。組件之間的依賴關係和接口的重要性，在將各個組件組裝在一起的時候得以體現。通過這中開發模式，我們還獲得了一種能力，可以隨意更換接口的實現。更換接口的實現，而不是接口，例如：電腦採用什麼樣的顯示器，隨你。你可以使用液晶的，也可以採用等離子顯示器，只要接口不變就可以了。
Spring提倡面向接口編程，也是基於這種的考慮，所謂的依賴注入，就是當某個角色，需要另外一個角色協助的時候，在傳統的程序當中，通常要實例化被調用者的實例，但是在 Spring裡面呢，創建被調用者的實例的工作，有Spring容器來實現。然後Spring容器會不把被調用者的實例注入到調用者那裡。依賴注入讓Bean與Bean之間的關係以配置文件的形式組織在一起。而不是以編碼的方式耦合在一起。
其實：不管是依賴注入還是控制反轉，都採用了Spring動態，靈活的方式來管理各種對象，對象之間的具體的實現是透明的。
動態代理模式：面向方面的編程：
AOP底層實現原理其實就是以動態代理的思想來實現的：
AOP
AOP是Spring的ICO依賴注入的一個補充和完善，使之成為一個更加有效的中間件，當然IOC容器並不依賴與AOP組件，因此我們可以認為AOP組件也不是必須的，Spring AOP的目標是提供Spring IOC容器緊密結合的AOP框架，Spring AOP 提供的是AOP與IOC容器的一個完美的結合。AOP從程序運行的角度考慮程序的結構，提供業務處理過程中的切面。
比如：我們要提供一個事務提交的切面，程序自上而下執行，當程序執行到事物提交這個操作的時候，程序的提交的判斷就可以交給切面監控程序去處理。而我們的主程序則，繼續往下執行，切面程序對於主程序來說，可以看作是透明的。AOP可以面向程序運行中的各步驟。這樣能夠很好的降低各個步驟之間的耦合性從而提高步驟之間的隔離。