一. 前言
spring源碼非常注重程序設計，對於我這初學者的提高一定。。。
idea非常火，是時候拋棄eclipse嘗試idea了（個人建議）
二. 準備工作
2.1 從github上下載spring源碼的zip文件，地址爲
2.2 自然少不了gradle項目構建工具（spring源碼在github上是通過gradle管理的，雖然說之前我從沒用過這個東東）。下載地址：
2.3 自然少不了idea，可谷歌可百度下載穩定（社區）版idea即可。
2.4 將下載的源碼導入到idea中，網上教程不少，比如這位前輩的見解。
2.5暫時沒有了
三. 軟件設計模式
學習之前先了解一下軟件設計模式，spring源碼中處處都體現了設計模式（筆者聽大牛說的，暫時還沒看過）。所以現將所有軟件設計模式瞭解一下，然後在學習的過程中，希望能夠對號入座。。（有點困難啊）
設計模式四要素：模式名稱；問題；解決方案；效果。
常見23中設計模式概述(轉載自
http://www.cnblogs.com/hj123/articles/4148274.html)
http://www.runoob.com/design-pattern/abstract-factory-pattern.html
1).抽象工廠模式（Abstract Factory）
提供一個創建一系列相關或相互依賴對象的接口，而無需指定他們具體的類。
比如某個產品X和Y，分別由A1，B1和A2，B2組成，那麼可以設計一個抽象工廠接口，封裝了A和B的生產方法。但是在實現的時候X產品實現的時A1和B1，Y產品實現的是A2和B2。可能還有個Z產品實現的是A3和B3。。2).適配器模式（Adapter） 將一個類的接口轉換成客戶希望的另外一個接口。適配器模式使得原本由於接口不兼容而不能一起工作的類可以一起工作。
> 比如讀卡器是作爲內存卡與筆記本之間的適配器。電源適配器。JAVA中的JDBC。在LINUX上運行WINDOWS程序。
> 主要解決：軟件系統中，常常將一些“現存的對象”放到新環境中，而新環境要求的接口是現對象不能滿足的。
> 解決方案：適配器繼承或依賴已有的對象，實現想要的目標接口。
> 優點：可以讓兩個沒有關聯的類一起運行。提高了類的複用性。增加了類的透明度。靈活性好。
> 缺點：過多使用會讓系統非常亂。java至多隻能適配一個適配者類。
> 注意：適配器不是在詳細設計時添加的，是解決正在服役項目中的問題。3). 橋接模式（Bridge）
用於將抽象化與實現化解耦，通過提供抽象畫與實現化之間的橋接結構，來實現二者的解耦。
意圖：將抽象部分與實現部分分離，使他們可以獨立地變化。
主要解決：在有多種可能會變化的情況下，用繼承會造成類爆炸問題，擴展起來不靈活。
何時使用：實現系統可能有多個角度分類，每一種角度都可能變化。
如何解決：把這多種角度分離出來，讓他們獨立變化，減少他們之間的耦合。
關鍵代碼：抽象類依賴實現類。
應用實例：牆上的開關，開關是抽象的不用管裏面具體如何實現的。
優點：1.抽象與實現分離。2.優秀的擴展能力3.實現細節對客戶透明
缺點：橋接模式的引入會增加系統的理解與設計難度，聚合關係建立在抽象層，要求開發者針對抽象進行設計與編程。
使用場景：如果一個系統需要在構件的抽象化角色與具體化角色之間增加更多的靈活性，避免在兩個層次之間建立靜態的繼承關係，通過橋接模式可以使他們在抽象層建立一個關聯關係表。2.對於那些不希望繼承或因爲多層次繼承導致類的個數急劇增加的系統，橋接模式尤爲適用。3.一個類存在兩個獨立變化的維度，且這兩個維度都需要擴展。
4）建造者模式（Builder）
使用多個簡單的對象一步一步構建成一個複雜的對象，這種類型的設計模式屬於創建型模式，它提供了一種創建對象的最佳方式。一個builder類會一步一步構造成最終的對象。該builder類獨立於其他對象的。
意圖:將一個複雜的構建與其表示相分離。使得同樣的構建過程可以創建不同的表示。
主要解決：在軟件系統中，一個複雜對象的創建工作，其通常由各個部分的子對象用一定的算法構成，由於需求的變化，這個複雜對象的各個部分經常面臨着劇烈的變化，但是將他們組合在一起的算法相對穩定。
何時使用：一些基本部件不會變，而其組合經常變化的時候。
如何解決：將變與不變分離開來。
關鍵代碼：建造者：創建和提供實例。導演：管理建造出來的實例的依賴關係。
應用實例：java中的StringBUilder。2.去麥當勞，漢堡，可樂，炸雞。薯條是不變的。但是他們時常會組合成不同的套餐。
優點：建造者獨立，易擴展，便於控制細節風險。
缺點：產品必須有共同點，範圍有限制。如內部構造複雜，會有很多的建造類。
使用場景：1.需要生成的對象具有複雜的得內部結構，需要生成的對象內部屬性本身相互依賴。
注意事項：與工廠模式區別，建造者模式更加關注與零件裝配的順序。
5) 責任鏈模式（chain of responsibility）
責任鏈模式爲請求創建了一個接收者對象的鏈。這種模式給與請求的類型，對請求的發送者和接收者進行解耦。這種類型的設計模式屬於行爲型模式。
意圖：避免請求的發送者與接收者耦合在一起，讓多個對象都有可能接受請求，把這些對象連接成一條鏈，並且沿着這條鏈傳遞請求，直到有對象處理它爲止。
主要解決：職責鏈上的處理者負責處理請求，客戶只需要將請求發送到責任鏈上即可，無須關心請求的處理細節和請求的傳遞，所以責任鏈將請求的發送者和請求的處理者解耦了。
何時使用：在處理消息的時候過濾很多道
如何解決：攔截的類都實現統一接口
關鍵代碼：handler裏面聚合他自己，在handler裏判斷是否合適，如何沒達到條件則向下傳遞，向誰傳遞之前set進去。
應用實例：js事件冒泡。javaweb中apach tomcat對encoding的處理。struts2的攔截器。jsp filter的filter。
優點：1.降低耦合度，它將請求的發送者和接收者解耦。2.簡化了對象，使得對象不需要知道鏈的結構。3.增強給對象指派職責的靈活性。通過改變鏈內的成員或調動他們的次序，允許動態地新增或者刪除責任。4增加新的請求處理類很方便。
缺點：1.不能保證請求一定被接收2.系統性能將受到一定影響，在進行代碼調試時也不太方便，可能造成循環調用3.
可能不容易觀察運行的特徵，有礙於除錯。
使用場景：1.有多個對象可以處理統一請求，具體哪個對象處理該請求由運行時刻自行確定。2.在不明確指定接收者的情況下，向多個對象中的一個提交一個請求。3.可動態指定一組對象處理請求。
注意事項：在javaweb中遇到很多應用。6）命令模式(Command Pattern)
命令模式是一種數據驅動的設計模式，它屬於行爲型模式。請求以命令的形式包裹在對象中，並傳給調用對象。調用對象尋找可以處理該命令的合適的對象，並把該命令傳給相應的對象，該對象執行命令。
意圖：將一個請求封裝成一個對象，從而使您可以用不同的請求對客戶進行參數化。
主要解決：在軟件系統中，行爲請求者與行爲實現者通常是一種緊耦合的關係，但某些場合，比如需要對行爲進行記錄、撤銷或重做、事務等處理時，這種無法抵禦變化的緊耦合的設計就不太合適。
何時使用：在某些場合，比如要對行爲進行"記錄、撤銷/重做、事務"等處理，這種無法抵禦變化的緊耦合是不合適的。在這種情況下，如何將"行爲請求者"與"行爲實現者"解耦？將一組行爲抽象爲對象，可以實現二者之間的松耦合。
如何解決：通過調用者調用接受者執行命令，順序：調用者→接受者→命令。
關鍵代碼：定義三個角色：1、received 真正的命令執行對象 2、Command 3、invoker 使用命令對象的入口
應用實例：struts 1 中的 action 核心控制器 ActionServlet 只有一個，相當於 Invoker，而模型層的類會隨着不同的應用有不同的模型類，相當於具體的 Command。
優點： 1、降低了系統耦合度。 2、新的命令可以很容易添加到系統中去。
缺點：使用命令模式可能會導致某些系統有過多的具體命令類。
使用場景：認爲是命令的地方都可以使用命令模式，比如： 1、GUI 中每一個按鈕都是一條命令。 2、模擬 CMD。
注意事項：系統需要支持命令的撤銷(Undo)操作和恢復(Redo)操作，也可以考慮使用命令模式，見命令模式的擴展。7) 組合模式（composite pattern）
組合模式，又叫部分整體模式，是用於把一組相似的對象當作一個單一的對象。組合模式依據樹形結構來組合對象，用來表示部分以及整體層次。這種類型的設計模式屬於結構型模式，它創建了對象組的樹形結構。
這種模式創建了一個包含自己對象組的類。該類提供了修改相同對象組的方式。
我們通過下面的實例來演示組合模式的用法。實例演示了一個組織中員工的層次結構。
意圖：將對象組合成樹形結構以表示"部分-整體"的層次結構。組合模式使得用戶對單個對象和組合對象的使用具有一致性。
主要解決：它在我們樹型結構的問題中，模糊了簡單元素和複雜元素的概念，客戶程序可以向處理簡單元素一樣來處理複雜元素，從而使得客戶程序與複雜元素的內部結構解耦。
何時使用： 1、您想表示對象的部分-整體層次結構（樹形結構）。 2、您希望用戶忽略組合對象與單個對象的不同，用戶將統一地使用組合結構中的所有對象。
如何解決：樹枝和葉子實現統一接口，樹枝內部組合該接口。
關鍵代碼：樹枝內部組合該接口，並且含有內部屬性 List，裏面放 Component。
應用實例： 1、算術表達式包括操作數、操作符和另一個操作數，其中，另一個操作符也可以是操作樹、操作符和另一個操作數。 2、在 JAVA AWT 和 SWING 中，對於 Button 和 Checkbox 是樹葉，Container 是樹枝。
優點： 1、高層模塊調用簡單。 2、節點自由增加。
缺點：在使用組合模式時，其葉子和樹枝的聲明都是實現類，而不是接口，違反了依賴倒置原則。
使用場景：部分、整體場景，如樹形菜單，文件、文件夾的管理。
注意事項：定義時爲具體類。8)裝飾器模式（Decorator）
裝飾器模式允許向一個現有的對象添加新的功能，同時又不改變其結構。這種類型的設計模式屬於結構型模式，它是作爲現有的類的一個包裝。
這種模式創建了一個裝飾類，用來包裝原有的類，並在保持類方法簽名完整性的前提下，提供了額外的功能。
意圖：動態地給一個對象添加一些額外的職責。就增加功能來說，裝飾器模式相比生成子類更爲靈活。
主要解決：一般的，我們爲了擴展一個類經常使用繼承方式實現，由於繼承爲類引入靜態特徵，並且隨着擴展功能的增多，子類會很膨脹。
何時使用：在不想增加很多子類的情況下擴展類。
如何解決：將具體功能職責劃分，同時繼承裝飾者模式。
關鍵代碼： 1、Component 類充當抽象角色，不應該具體實現。 2、修飾類引用和繼承 Component 類，具體擴展類重寫父類方法。
應用實例： 1、孫悟空有 72 變，當他變成"廟宇"後，他的根本還是一隻猴子，但是他又有了廟宇的功能。 2、不論一幅畫有沒有畫框都可以掛在牆上，但是通常都是有畫框的，並且實際上是畫框被掛在牆上。在掛在牆上之前，畫可以被蒙上玻璃，裝到框子裏；這時畫、玻璃和畫框形成了一個物體。
優點：裝飾類和被裝飾類可以獨立發展，不會相互耦合，裝飾模式是繼承的一個替代模式，裝飾模式可以動態擴展一個實現類的功能。
缺點：多層裝飾比較複雜。
使用場景： 1、擴展一個類的功能。 2、動態增加功能，動態撤銷。
注意事項：可代替繼承。9 ) 門面模式（frcade）
爲子系統的一組接口提供一個一致的界面，門面模式定義了一個高層接口，這個接口使得這一子系統更加容易使用。
10）工廠模式（factory method）
工廠模式是 Java 中最常用的設計模式之一。這種類型的設計模式屬於創建型模式，它提供了一種創建對象的最佳方式。在工廠模式中，我們在創建對象時不會對客戶端暴露創建邏輯，並且是通過使用一個共同的接口來指向新創建的對象。
意圖：定義一個創建對象的接口，讓其子類自己決定實例化哪一個工廠類，工廠模式使其創建過程延遲到子類進行。
主要解決：主要解決接口選擇的問題。
何時使用：我們明確地計劃不同條件下創建不同實例時。
如何解決：讓其子類實現工廠接口，返回的也是一個抽象的產品。
關鍵代碼：創建過程在其子類執行。
應用實例： 1、您需要一輛汽車，可以直接從工廠裏面提貨，而不用去管這輛汽車是怎麼做出來的，以及這個汽車裏面的具體實現。 2、Hibernate 換數據庫只需換方言和驅動就可以。
優點： 1、一個調用者想創建一個對象，只要知道其名稱就可以了。 2、擴展性高，如果想增加一個產品，只要擴展一個工廠類就可以。 3、屏蔽產品的具體實現，調用者只關心產品的接口。
缺點：每次增加一個產品時，都需要增加一個具體類和對象實現工廠，使得系統中類的個數成倍增加，在一定程度上增加了系統的複雜度，同時也增加了系統具體類的依賴。這並不是什麼好事。
使用場景： 1、日誌記錄器：記錄可能記錄到本地硬盤、系統事件、遠程服務器等，用戶可以選擇記錄日誌到什麼地方。 2、數據庫訪問，當用戶不知道最後系統採用哪一類數據庫，以及數據庫可能有變化時。 3、設計一個連接服務器的框架，需要三個協議，"POP3"、"IMAP"、"HTTP"，可以把這三個作爲產品類，共同實現一個接口。
注意事項：作爲一種創建類模式，在任何需要生成複雜對象的地方，都可以使用工廠方法模式。有一點需要注意的地方就是複雜對象適合使用工廠模式，而簡單對象，特別是只需要通過 new 就可以完成創建的對象，無需使用工廠模式。如果使用工廠模式，就需要引入一個工廠類，會增加系統的複雜度。11)享元模式
享元模式（Flyweight Pattern）主要用於減少創建對象的數量，以減少內存佔用和提高性能。這種類型的設計模式屬於結構型模式，它提供了減少對象數量從而改善應用所需的對象結構的方式.享元模式嘗試重用現有的同類對象，如果未找到匹配的對象，則創建新對象。
意圖：運用共享技術有效地支持大量細粒度的對象。
主要解決：在有大量對象時，有可能會造成內存溢出，我們把其中共同的部分抽象出來，如果有相同的業務請求，直接返回在內存中已有的對象，避免重新創建。
何時使用： 1、系統中有大量對象。 2、這些對象消耗大量內存。 3、這些對象的狀態大部分可以外部化。 4、這些對象可以按照內蘊狀態分爲很多組，當把外蘊對象從對象中剔除出來時，每一組對象都可以用一個對象來代替。 5、系統不依賴於這些對象身份，這些對象是不可分辨的。
如何解決：用唯一標識碼判斷，如果在內存中有，則返回這個唯一標識碼所標識的對象。
關鍵代碼：用 HashMap 存儲這些對象。
應用實例： 1、JAVA 中的 String，如果有則返回，如果沒有則創建一個字符串保存在字符串緩存池裏面。 2、數據庫的數據池。
優點：大大減少對象的創建，降低系統的內存，使效率提高。
缺點：提高了系統的複雜度，需要分離出外部狀態和內部狀態，而且外部狀態具有固有化的性質，不應該隨着內部狀態的變化而變化，否則會造成系統的混亂。
使用場景： 1、系統有大量相似對象。 2、需要緩衝池的場景。
注意事項： 1、注意劃分外部狀態和內部狀態，否則可能會引起線程安全問題。 2、這些類必須有一個工廠對象加以控制。12）解釋器模式
解釋器模式（Interpreter Pattern）提供了評估語言的語法或表達式的方式，它屬於行爲型模式。這種模式實現了一個表達式接口，該接口解釋一個特定的上下文。這種模式被用在 SQL 解析、符號處理引擎等。
意圖：給定一個語言，定義它的文法表示，並定義一個解釋器，這個解釋器使用該標識來解釋語言中的句子。
主要解決：對於一些固定文法構建一個解釋句子的解釋器。
何時使用：如果一種特定類型的問題發生的頻率足夠高，那麼可能就值得將該問題的各個實例表述爲一個簡單語言中的句子。這樣就可以構建一個解釋器，該解釋器通過解釋這些句子來解決該問題。
如何解決：構件語法樹，定義終結符與非終結符。
關鍵代碼：構件環境類，包含解釋器之外的一些全局信息，一般是 HashMap。
應用實例：編譯器、運算表達式計算。
優點： 1、可擴展性比較好，靈活。 2、增加了新的解釋表達式的方式。 3、易於實現簡單文法。
缺點： 1、可利用場景比較少。 2、對於複雜的文法比較難維護。 3、解釋器模式會引起類膨脹。 4、解釋器模式採用遞歸調用方法。
使用場景： 1、可以將一個需要解釋執行的語言中的句子表示爲一個抽象語法樹。 2、一些重複出現的問題可以用一種簡單的語言來進行表達。 3、一個簡單語法需要解釋的場景。
注意事項：可利用場景比較少，JAVA 中如果碰到可以用 expression4J 代替。13）迭代器模式
迭代器模式（Iterator Pattern）是 Java 和 .Net 編程環境中非常常用的設計模式。這種模式用於順序訪問集合對象的元素，不需要知道集合對象的底層表示。迭代器模式屬於行爲型模式。
意圖：提供一種方法順序訪問一個聚合對象中各個元素, 而又無須暴露該對象的內部表示。
主要解決：不同的方式來遍歷整個整合對象。
何時使用：遍歷一個聚合對象。
如何解決：把在元素之間遊走的責任交給迭代器，而不是聚合對象。
關鍵代碼：定義接口：hasNext, next。
應用實例：JAVA 中的 iterator。
優點： 1、它支持以不同的方式遍歷一個聚合對象。 2、迭代器簡化了聚合類。 3、在同一個聚合上可以有多個遍歷。 4、在迭代器模式中，增加新的聚合類和迭代器類都很方便，無須修改原有代碼。
缺點：由於迭代器模式將存儲數據和遍歷數據的職責分離，增加新的聚合類需要對應增加新的迭代器類，類的個數成對增加，這在一定程度上增加了系統的複雜性。
使用場景： 1、訪問一個聚合對象的內容而無須暴露它的內部表示。 2、需要爲聚合對象提供多種遍歷方式。 3、爲遍歷不同的聚合結構提供一個統一的接口。
注意事項：迭代器模式就是分離了集合對象的遍歷行爲，抽象出一個迭代器類來負責，這樣既可以做到不暴露集合的內部結構，又可讓外部代碼透明地訪問集合內部的數據
14）：中介者模式
中介者模式（Mediator Pattern）是用來降低多個對象和類之間的通信複雜性。提供了一箇中介類，該類通常處理不同類之間的通信，並支持松耦合，使代碼易於維護。中介者屬於行爲型模式。
意圖：用一箇中介對象來封裝一系列的對象交互，中介者使各對象不需要顯式地相互引用，從而使其耦合鬆散，而且可以獨立地改變它們之間的交互。
主要解決：對象與對象之間存在大量的關聯關係，這樣勢必會導致系統的結構變得很複雜，同時若一個對象發生改變，我們也需要跟蹤與之相關聯的對象，同時做出相應的處理。
何時使用：多個類相互耦合，形成了網狀結構。
如何解決：將上述網狀結構分離爲星型結構。
關鍵代碼：對象 Colleague 之間的通信封裝到一個類中單獨處理。
應用實例： 1、中國加入 WTO 之前是各個國家相互貿易，結構複雜，現在是各個國家通過 WTO 來互相貿易。 2、機場調度系統。 3、MVC 框架，其中C（控制器）就是 M（模型）和 V（視圖）的中介者。
優點： 1、降低了類的複雜度，將一對多轉化成了一對一。 2、各個類之間的解耦。 3、符合迪米特原則。
缺點：中介者會龐大，變得複雜難以維護。
使用場景： 1、系統中對象之間存在比較複雜的引用關係，導致它們之間的依賴關係結構混亂而且難以複用該對象。 2、想通過一箇中間類來封裝多個類中的行爲，而又不想生成太多的子類。
注意事項：不應當在職責混亂的時候使用。15）：備忘錄模式
備忘錄模式（Memento Pattern）保存一個對象的某個狀態，以便在適當的時候恢復對象。備忘錄模式屬於行爲型模式。
意圖：在不破壞封裝性的前提下，捕獲一個對象的內部狀態，並在該對象之外保存這個狀態。
主要解決：所謂備忘錄模式就是在不破壞封裝的前提下，捕獲一個對象的內部狀態，並在該對象之外保存這個狀態，這樣可以在以後將對象恢復到原先保存的狀態。
何時使用：很多時候我們總是需要記錄一個對象的內部狀態，這樣做的目的就是爲了允許用戶取消不確定或者錯誤的操作，能夠恢復到他原先的狀態，使得他有"後悔藥"可喫。
如何解決：通過一個備忘錄類專門存儲對象狀態。
關鍵代碼：客戶不與備忘錄類耦合，與備忘錄管理類耦合。
應用實例： 1、後悔藥。 2、打遊戲時的存檔。 3、Windows 裏的 ctri + z。 4、IE 中的後退。 4、數據庫的事務管理。
優點： 1、給用戶提供了一種可以恢復狀態的機制，可以使用戶能夠比較方便地回到某個歷史的狀態。 2、實現了信息的封裝，使得用戶不需要關心狀態的保存細節。
缺點：消耗資源。如果類的成員變量過多，勢必會佔用比較大的資源，而且每一次保存都會消耗一定的內存。
使用場景： 1、需要保存/恢復數據的相關狀態場景。 2、提供一個可回滾的操作。
注意事項： 1、爲了符合迪米特原則，還要增加一個管理備忘錄的類。 2、爲了節約內存，可使用原型模式+備忘錄模式16）觀察者模式
當對象間存在一對多關係時，則使用觀察者模式（Observer Pattern）。比如，當一個對象被修改時，則會自動通知它的依賴對象。觀察者模式屬於行爲型模式。
意圖：定義對象間的一種一對多的依賴關係，當一個對象的狀態發生改變時，所有依賴於它的對象都得到通知並被自動更新。
主要解決：一個對象狀態改變給其他對象通知的問題，而且要考慮到易用和低耦合，保證高度的協作。
何時使用：一個對象（目標對象）的狀態發生改變，所有的依賴對象（觀察者對象）都將得到通知，進行廣播通知。
如何解決：使用面向對象技術，可以將這種依賴關係弱化。
關鍵代碼：在抽象類裏有一個 ArrayList 存放觀察者們。
應用實例： 1、拍賣的時候，拍賣師觀察最高標價，然後通知給其他競價者競價。 2、西遊記裏面悟空請求菩薩降服紅孩兒，菩薩灑了一地水招來一個老烏龜，這個烏龜就是觀察者，他觀察菩薩灑水這個動作。
優點： 1、觀察者和被觀察者是抽象耦合的。 2、建立一套觸發機制。
缺點： 1、如果一個被觀察者對象有很多的直接和間接的觀察者的話，將所有的觀察者都通知到會花費很多時間。 2、如果在觀察者和觀察目標之間有循環依賴的話，觀察目標會觸發它們之間進行循環調用，可能導致系統崩潰。 3、觀察者模式沒有相應的機制讓觀察者知道所觀察的目標對象是怎麼發生變化的，而僅僅只是知道觀察目標發生了變化。
使用場景： 1、有多個子類共有的方法，且邏輯相同。 2、重要的、複雜的方法，可以考慮作爲模板方法。
注意事項： 1、JAVA 中已經有了對觀察者模式的支持類。 2、避免循環引用。 3、如果順序執行，某一觀察者錯誤會導致系統卡殼，一般採用異步方式。17）：原型模式
原型模式（Prototype Pattern）是用於創建重複的對象，同時又能保證性能。這種類型的設計模式屬於創建型模式，它提供了一種創建對象的最佳方式。
這種模式是實現了一個原型接口，該接口用於創建當前對象的克隆。當直接創建對象的代價比較大時，則採用這種模式。例如，一個對象需要在一個高代價的數據庫操作之後被創建。我們可以緩存該對象，在下一個請求時返回它的克隆，在需要的時候更新數據庫，以此來減少數據庫調用。
意圖：用原型實例指定創建對象的種類，並且通過拷貝這些原型創建新的對象。
主要解決：在運行期建立和刪除原型。
何時使用： 1、當一個系統應該獨立於它的產品創建，構成和表示時。 2、當要實例化的類是在運行時刻指定時，例如，通過動態裝載。 3、爲了避免創建一個與產品類層次平行的工廠類層次時。 4、當一個類的實例只能有幾個不同狀態組合中的一種時。建立相應數目的原型並克隆它們可能比每次用合適的狀態手工實例化該類更方便一些。
如何解決：利用已有的一個原型對象，快速地生成和原型對象一樣的實例。
關鍵代碼： 1、實現克隆操作，在 JAVA 繼承 Cloneable，重寫 clone()，在 .NET 中可以使用 Object 類的 MemberwiseClone() 方法來實現對象的淺拷貝或通過序列化的方式來實現深拷貝。 2、原型模式同樣用於隔離類對象的使用者和具體類型（易變類）之間的耦合關係，它同樣要求這些"易變類"擁有穩定的接口。
應用實例： 1、細胞分裂。 2、JAVA 中的 Object clone() 方法。
優點： 1、性能提高。 2、逃避構造函數的約束。
缺點： 1、配備克隆方法需要對類的功能進行通盤考慮，這對於全新的類不是很難，但對於已有的類不一定很容易，特別當一個類引用不支持串行化的間接對象，或者引用含有循環結構的時候。 2、必須實現 Cloneable 接口。 3、逃避構造函數的約束。
使用場景： 1、資源優化場景。 2、類初始化需要消化非常多的資源，這個資源包括數據、硬件資源等。 3、性能和安全要求的場景。 4、通過 new 產生一個對象需要非常繁瑣的數據準備或訪問權限，則可以使用原型模式。 5、一個對象多個修改者的場景。 6、一個對象需要提供給其他對象訪問，而且各個調用者可能都需要修改其值時，可以考慮使用原型模式拷貝多個對象供調用者使用。 7、在實際項目中，原型模式很少單獨出現，一般是和工廠方法模式一起出現，通過 clone 的方法創建一個對象，然後由工廠方法提供給調用者。原型模式已經與 Java 融爲渾然一體，大家可以隨手拿來使用。
注意事項：與通過對一個類進行實例化來構造新對象不同的是，原型模式是通過拷貝一個現有對象生成新對象的。淺拷貝實現 Cloneable，重寫，深拷貝是通過實現 Serializable 讀取二進制流18)：代理模式
在代理模式（Proxy Pattern）中，一個類代表另一個類的功能。這種類型的設計模式屬於結構型模式。
在代理模式中，我們創建具有現有對象的對象，以便向外界提供功能接口。
意圖：爲其他對象提供一種代理以控制對這個對象的訪問。
主要解決：在直接訪問對象時帶來的問題，比如說：要訪問的對象在遠程的機器上。在面向對象系統中，有些對象由於某些原因（比如對象創建開銷很大，或者某些操作需要安全控制，或者需要進程外的訪問），直接訪問會給使用者或者系統結構帶來很多麻煩，我們可以在訪問此對象時加上一個對此對象的訪問層。
何時使用：想在訪問一個類時做一些控制。
如何解決：增加中間層。
關鍵代碼：實現與被代理類組合。
應用實例： 1、Windows 裏面的快捷方式。 2、豬八戒去找高翠蘭結果是孫悟空變的，可以這樣理解：把高翠蘭的外貌抽象出來，高翠蘭本人和孫悟空都實現了這個接口，豬八戒訪問高翠蘭的時候看不出來這個是孫悟空，所以說孫悟空是高翠蘭代理類。 3、買火車票不一定在火車站買，也可以去代售點。 4、一張支票或銀行存單是賬戶中資金的代理。支票在市場交易中用來代替現金，並提供對簽發人賬號上資金的控制。 5、spring aop。
優點： 1、職責清晰。 2、高擴展性。 3、智能化。
缺點： 1、由於在客戶端和真實主題之間增加了代理對象，因此有些類型的代理模式可能會造成請求的處理速度變慢。 2、實現代理模式需要額外的工作，有些代理模式的實現非常複雜。
使用場景：按職責來劃分，通常有以下使用場景： 1、遠程代理。 2、虛擬代理。 3、Copy-on-Write 代理。 4、保護（Protect or Access）代理。 5、Cache代理。 6、防火牆（Firewall）代理。 7、同步化（Synchronization）代理。 8、智能引用（Smart Reference）代理。
注意事項： 1、和適配器模式的區別：適配器模式主要改變所考慮對象的接口，而代理模式不能改變所代理類的接口。 2、和裝飾器模式的區別：裝飾器模式爲了增強功能，而代理模式是爲了加以控制。
19）：單例模式
單例模式（Singleton Pattern）是 Java 中最簡單的設計模式之一。這種類型的設計模式屬於創建型模式，它提供了一種創建對象的最佳方式。
這種模式涉及到一個單一的類，該類負責創建自己的對象，同時確保只有單個對象被創建。這個類提供了一種訪問其唯一的對象的方式，可以直接訪問，不需要實例化該類的對象。
注意：
1、單例類只能有一個實例。
2、單例類必須自己創建自己的唯一實例。
3、單例類必須給所有其他對象提供這一實例。
意圖：保證一個類僅有一個實例，並提供一個訪問它的全局訪問點。
主要解決：一個全局使用的類頻繁地創建與銷燬。
何時使用：當您想控制實例數目，節省系統資源的時候。
如何解決：判斷系統是否已經有這個單例，如果有則返回，如果沒有則創建。
關鍵代碼：構造函數是私有的。
應用實例： 1、一個黨只能有一個主席。 2、Windows 是多進程多線程的，在操作一個文件的時候，就不可避免地出現多個進程或線程同時操作一個文件的現象，所以所有文件的處理必須通過唯一的實例來進行。 3、一些設備管理器常常設計爲單例模式，比如一個電腦有兩臺打印機，在輸出的時候就要處理不能兩臺打印機打印同一個文件。
優點： 1、在內存裏只有一個實例，減少了內存的開銷，尤其是頻繁的創建和銷燬實例（比如管理學院首頁頁面緩存）。 2、避免對資源的多重佔用（比如寫文件操作）。
缺點：沒有接口，不能繼承，與單一職責原則衝突，一個類應該只關心內部邏輯，而不關心外面怎麼樣來實例化。
使用場景： 1、要求生產唯一序列號。 2、WEB 中的計數器，不用每次刷新都在數據庫里加一次，用單例先緩存起來。 3、創建的一個對象需要消耗的資源過多，比如 I/O 與數據庫的連接等。
注意事項：getInstance() 方法中需要使用同步鎖 synchronized (Singleton.class) 防止多線程同時進入造成 instance 被多次實例化。20):狀態模式
在狀態模式（State Pattern）中，類的行爲是基於它的狀態改變的。這種類型的設計模式屬於行爲型模式。
在狀態模式中，我們創建表示各種狀態的對象和一個行爲隨着狀態對象改變而改變的 context 對象。
意圖：允許對象在內部狀態發生改變時改變它的行爲，對象看起來好像修改了它的類。
主要解決：對象的行爲依賴於它的狀態（屬性），並且可以根據它的狀態改變而改變它的相關行爲。
何時使用：代碼中包含大量與對象狀態有關的條件語句。
如何解決：將各種具體的狀態類抽象出來。
關鍵代碼：通常命令模式的接口中只有一個方法。而狀態模式的接口中有一個或者多個方法。而且，狀態模式的實現類的方法，一般返回值，或者是改變實例變量的值。也就是說，狀態模式一般和對象的狀態有關。實現類的方法有不同的功能，覆蓋接口中的方法。狀態模式和命令模式一樣，也可以用於消除 if...else 等條件選擇語句。
應用實例： 1、打籃球的時候運動員可以有正常狀態、不正常狀態和超常狀態。 2、曾侯乙編鐘中，'鍾是抽象接口','鍾A'等是具體狀態，'曾侯乙編鐘'是具體環境（Context）。
優點： 1、封裝了轉換規則。 2、枚舉可能的狀態，在枚舉狀態之前需要確定狀態種類。 3、將所有與某個狀態有關的行爲放到一個類中，並且可以方便地增加新的狀態，只需要改變對象狀態即可改變對象的行爲。 4、允許狀態轉換邏輯與狀態對象合成一體，而不是某一個巨大的條件語句塊。 5、可以讓多個環境對象共享一個狀態對象，從而減少系統中對象的個數。
缺點： 1、狀態模式的使用必然會增加系統類和對象的個數。 2、狀態模式的結構與實現都較爲複雜，如果使用不當將導致程序結構和代碼的混亂。 3、狀態模式對"開閉原則"的支持並不太好，對於可以切換狀態的狀態模式，增加新的狀態類需要修改那些負責狀態轉換的源代碼，否則無法切換到新增狀態，而且修改某個狀態類的行爲也需修改對應類的源代碼。
使用場景： 1、行爲隨狀態改變而改變的場景。 2、條件、分支語句的代替者。
注意事項：在行爲受狀態約束的時候使用狀態模式，而且狀態不超過 5 個。21):策略模式
在策略模式（Strategy Pattern）中，一個類的行爲或其算法可以在運行時更改。這種類型的設計模式屬於行爲型模式。
在策略模式中，我們創建表示各種策略的對象和一個行爲隨着策略對象改變而改變的 context 對象。策略對象改變 context 對象的執行算法。
意圖：定義一系列的算法,把它們一個個封裝起來, 並且使它們可相互替換。
主要解決：在有多種算法相似的情況下，使用 if...else 所帶來的複雜和難以維護。
何時使用：一個系統有許多許多類，而區分它們的只是他們直接的行爲。
如何解決：將這些算法封裝成一個一個的類，任意地替換。
關鍵代碼：實現同一個接口。
應用實例： 1、諸葛亮的錦囊妙計，每一個錦囊就是一個策略。 2、旅行的出遊方式，選擇騎自行車、坐汽車，每一種旅行方式都是一個策略。 3、JAVA AWT 中的 LayoutManager。
優點： 1、算法可以自由切換。 2、避免使用多重條件判斷。 3、擴展性良好。
缺點： 1、策略類會增多。 2、所有策略類都需要對外暴露。
使用場景： 1、如果在一個系統裏面有許多類，它們之間的區別僅在於它們的行爲，那麼使用策略模式可以動態地讓一個對象在許多行爲中選擇一種行爲。 2、一個系統需要動態地在幾種算法中選擇一種。 3、如果一個對象有很多的行爲，如果不用恰當的模式，這些行爲就只好使用多重的條件選擇語句來實現。
注意事項：如果一個系統的策略多於四個，就需要考慮使用混合模式，解決策略類膨脹的問題。22):模板模式
在模板模式（Template Pattern）中，一個抽象類公開定義了執行它的方法的方式/模板。它的子類可以按需要重寫方法實現，但調用將以抽象類中定義的方式進行。這種類型的設計模式屬於行爲型模式。
意圖：定義一個操作中的算法的骨架，而將一些步驟延遲到子類中。模板方法使得子類可以不改變一個算法的結構即可重定義該算法的某些特定步驟。
主要解決：一些方法通用，卻在每一個子類都重新寫了這一方法。
何時使用：有一些通用的方法。
如何解決：將這些通用算法抽象出來。
關鍵代碼：在抽象類實現，其他步驟在子類實現。
應用實例： 1、在造房子的時候，地基、走線、水管都一樣，只有在建築的後期纔有加壁櫥加柵欄等差異。 2、西遊記裏面菩薩定好的 81 難，這就是一個頂層的邏輯骨架。 3、spring 中對 Hibernate 的支持，將一些已經定好的方法封裝起來，比如開啓事務、獲取 Session、關閉 Session 等，程序員不重複寫那些已經規範好的代碼，直接丟一個實體就可以保存。
優點： 1、封裝不變部分，擴展可變部分。 2、提取公共代碼，便於維護。 3、行爲由父類控制，子類實現。
缺點：每一個不同的實現都需要一個子類來實現，導致類的個數增加，使得系統更加龐大。
使用場景： 1、有多個子類共有的方法，且邏輯相同。 2、重要的、複雜的方法，可以考慮作爲模板方法。
注意事項：爲防止惡意操作，一般模板方法都加上 final 關鍵詞。23):訪問者模式
在訪問者模式（Visitor Pattern）中，我們使用了一個訪問者類，它改變了元素類的執行算法。通過這種方式，元素的執行算法可以隨着訪問者改變而改變。這種類型的設計模式屬於行爲型模式。根據模式，元素對象已接受訪問者對象，這樣訪問者對象就可以處理元素對象上的操作。
意圖：主要將數據結構與數據操作分離。
主要解決：穩定的數據結構和易變的操作耦合問題。
何時使用：需要對一個對象結構中的對象進行很多不同的並且不相關的操作，而需要避免讓這些操作"污染"這些對象的類，使用訪問者模式將這些封裝到類中。
如何解決：在被訪問的類裏面加一個對外提供接待訪問者的接口。
關鍵代碼：在數據基礎類裏面有一個方法接受訪問者，將自身引用傳入訪問者。
應用實例：您在朋友家做客，您是訪問者，朋友接受您的訪問，您通過朋友的描述，然後對朋友的描述做出一個判斷，這就是訪問者模式。
優點： 1、符合單一職責原則。 2、優秀的擴展性。 3、靈活性。
缺點： 1、具體元素對訪問者公佈細節，違反了迪米特原則。 2、具體元素變更比較困難。 3、違反了依賴倒置原則，依賴了具體類，沒有依賴抽象。
使用場景： 1、對象結構中對象對應的類很少改變，但經常需要在此對象結構上定義新的操作。 2、需要對一個對象結構中的對象進行很多不同的並且不相關的操作，而需要避免讓這些操作"污染"這些對象的類，也不希望在增加新操作時修改這些類。
注意事項：訪問者可以對功能進行統一，可以做報表、UI、攔截器與過濾器。
四：springCore閱讀心得