【設計模式之禪 第2版】讀書筆記

本身練習的源碼地址：https://git.oschina.net/snnhoo/DesignPattern.git  歡迎推送

 

第一章 單一職責原則

1. 簡稱SRP：Single Responsibility Principle
2. 定義：應該有且僅有一個緣由引發類的變動
3. 好處：
1. 類複雜度下降，職責明確
2. 可讀性高
3. 可維護性高
4. 變動引發風險低
4. 接口設計要單一，實現要根據狀況，方法也適用單一職責

 

第二章 里氏替換原則

1. 定義：父類能出現的地方就能用子類，且不會產生任何異常，可是反過來則不行，有子類出現的地方，父類未必能適應。
2. 在類中調用其它類時務必使用父類或接口，若是不能使用則說明類的設計違背了LSP原則。
3. 若是子類不能完整實現父類方法，或某些方法發生「畸變」，則斷開繼承，採用依賴、彙集、組合。
4. 採用里氏替換原則時，儘可能避免子類的「個性」，若是用父類則抹殺子類個性，若是用子類則缺少類替換標準。
5. 子類必須實現父類全部方法，且是須要的。
6. 子類能夠有本身獨特的方法。
7. 子類方法中的參數要與父類同方法中參數相同或更寬鬆。
8. 在重寫狀況下同一方法子類返回值類型要小於等於父類返回值類型。

9. 里氏替換原則是開閉原則的具體實現之一。

 

第三章 依賴倒置原則

1. DIP：Dependence Inversion Principle
2. 定義：
1. 高層不該該依賴低層模塊，二者都應該依賴抽象（類間不發生直接依賴關係，其依賴經過接口或抽象類產生）
2. 抽象不該該依賴細節（接口或抽象類不依賴於實現類）
3. 細節應該依賴抽象（實現類應該依賴接口或抽象類）
3. 優勢：減小類間耦合性，提升系統穩定性，下降並行開發引發的風險（多人用接口同時開發，便於單元測試），提升可讀性維護性。
4. 最佳實踐
1. 每一個類儘可能都有抽象類或接口，或者同時都有
2. 變量的表面類型最好是接口或抽象類
3. 任何類都不該該從具體類派生
4. 儘可能不要覆寫基類的方法
5. 結合里氏替換：接口負責定義公共方法和屬性，抽象類負責公共構造部分的實現
5. 依賴正置：面向實現編程（類間依賴實現類）

 

第四章 接口隔離原則

1. 定義：客戶端不該該依賴它不須要的接口，類間的依賴關係應該創建在最小的接口上。
2. 單一職責是要求類和接口職責單一，是從業務邏輯劃分。接口隔離則要求方法要少，好比幾個模塊就應該有幾個接口，而不是一個大接口。
1. 好比說一個類不能有吃飯方法又有製造炸彈方法這是單一職責，好比一個類有讀寫2個方法，但有的類只能讀，有的類只能寫，這就要接口隔離。
3. 規範約束：
1. 接口儘可能小，根據接口隔離原則拆分時，首先必須知足單一職責原則。
2. 接口要高內聚，儘可能少公佈public方法。
3. 定製服務，爲特殊服務新開一個接口。
4. 接口設計有限度的。
4. 最佳實踐
1. 一個接口只服務於一個模塊或業務邏輯；
2. 經過業務邏輯壓縮接口中的public方法；
3. 已經被污染的接口，儘可能去修改，如風險大，則採用適配器模式轉化處理；
4. 瞭解環境，拒絕盲從。

 

第五章 迪米特法則

1. LoD：Law of Demeter，也稱最少知識原則LKP。
2. 定義：一個對象應該對其餘對象有最少的瞭解。
3. 對類的低耦合要求：
1. 只和朋友交流，出如今成員變量、方法的輸入輸出參數中的類稱爲朋友類，方法體內的不算。類與類之間的關係是創建在類間的，而不是方法間，所以一個方法儘可能不引入一個類中不存在的對象。
2. 朋友間也是有距離的，一個類公開的public屬性或方法越多，修改時涉及的面也就越大，變動引發的風險擴散也就越大。所以設計時須要反覆衡量是否能夠減小public方法或屬性。
3. 是本身的就是本身的，若是一個方法放在本類中，既不增長類間關係，也對本類不產生負面影響，那就放置在本類中。
4. 謹慎使用Serializable。

 

第六章 開閉原則

1. 定義：一個軟件實體如類、模塊、和函數應該對擴展開放，對修改關閉。
2. 前面五個原則就是指導設計的工具和方法，而開閉原則纔是其精神領袖。
3. 重要性：
1. 擴展操做，避免修改單元測試，及迴歸測試；
2. 提升代碼複用性，縮小邏輯粒度，直到一個邏輯不可再拆分爲止；
3. 提升可維護性；
4. 面向對象開發的要求。
4. 使用
1. 抽象約束
1. 經過接口或抽象類約束擴展，對擴展進行限定，不容許出如今接口或抽象類不存在的public方法；
2. 參數類型、引用對象儘可能使用接口或抽象類，而不是實現類；
3. 抽象層儘可能保持穩定，一旦肯定不容許修改。
2. 元數據控制模塊行爲，經過擴展一個子類，修改配置文件完成業務變化，如依賴注入；
3. 制定項目章程；
4. 封裝變化，找出預計有變化或不穩定的點，爲這些變化點建立穩定的接口
1. 將相同變化封裝到一個接口或抽象類中；
2. 不該該有兩個不一樣的變化出如今同一個接口或抽象類中；

 

第七章 單例模式

1. 定義：確保某一個類只有一個實例，並且自行實例化並向整個系統提供這個實例。
2. 優勢：
1. 單例模式在內存中只有一個實例，減小了內存開支，特別是一個頻繁操做，性能又沒法優化的對象。
2. 減小性能開銷，如讀取配置、產生其餘依賴對象時，啓動一個對象，永久駐留內存。
3. 能夠避免一個對象的多重佔用，例如一個寫文件動做。
4. 能夠設置系統全局訪問點，優化和共享資源訪問。
3. 缺點：
1. 單例模式通常沒有接口，沒法擴展。
2. 沒法測試，若是代碼未完成則沒法測試，且因沒有接口因此沒法mock。
3. 單例模式與單一職責原則有衝突，類應只關心內部實現，而不關心外部如何調用。
4. 使用場景：
1. 要求生成惟一序列號的環境。
2. 整個項目中須要一個共享訪問點或共享數據，如頁面訪問計數器。
3. 建立消耗資源過多的對象。
4. 須要定義大量靜態常量和靜態方法的環境。
5. 擴展：有上限的多例模式，能夠定義內部列表存儲實例，而後根據條件返回某實例。

 

第八章 工廠方法模式

1. 定義：定義一個用於建立對象的接口，讓子類決定實例化哪個類，工廠方法使一個類的實例化延遲到其子類。
2. 在工廠方法模式中， 抽象產品類Product負責定義產品的共性， 實現對事物最抽象的定義； Creator爲抽象建立類， 也就是抽象工廠， 具體如何建立產品類是由具體的實現工廠ConcreteCreator完成的。

 

4. 優勢：
1. 良好的封裝性，代碼接口清晰，調用者只須要知道產品約束字符串就能夠。
2. 擴展性高，增長產品時，只須要修改工廠類或擴展一個工廠類。
3. 屏蔽產品類，例如切換數據庫。
4. 典型的解耦框架，只知道抽象類，符合迪米特法則；只依賴產品抽象，符合依賴倒置原則；使用子類替換父類，符合里氏替換原則。
5. 應用場景：
1. 在new一個對象的地方均可以使用，尤爲是複雜對象時。
2. 須要靈活、可擴展框架時可以使用，如郵件，支持POP3、IMAP、HTTP。
3. 可用在異構項目中。
4. 測試驅動開發的框架下，模擬一個類。
6. 擴展：
1. 簡單工廠模式：去掉繼承抽象類，並在工廠建立對象方法前增長static關鍵字；
2. 多工廠模式：每一個產品對應一個建立工廠，好處是職責清洗符合單一職責原則，但不宜擴展和維護，通常新增一個協調類，來封裝子工廠。
3. 替代單例模式：工廠內設置靜態對象。
4. 延遲加載：保存特定對象在工廠，須要時直接返回，如數據庫最大鏈接數對象。

 

第九章 抽象工廠模式

1. 定義：爲建立一組相關或相互依賴的對象提供一個接口，並且無須指定他們的具體類。在場景類中，沒有任何一個方法與實現類有關係。
1. 產品族：指由同一個工廠生產的，位於不一樣產品等級結構中的一組產品，例如不一樣品牌的電視機。
2. 產品等級結構：產品的繼承結構，如抽象類是電視機，其子類有海爾電視機、海信電視機。

 

3. 有N個產品族，在抽象工廠類中就應該有N個建立方法。
4. 有M個產品等級就應該有M個實現工廠類，在每一個實現工廠中，實現不一樣產品族的生產任務。

5. 優勢：
1. 封裝性，每一個產品的實現類不須要高層模塊關心，只需關心接口抽象。
2. 產品族內的約束爲非公開狀態，具體約束實在工廠內實現，高層無須關心。
6. 缺點：產品族擴展很是困難，例如新增一個品牌產品，要在全部工廠方法中新增建立產品方法。
7. 應用場景：一個對象族或是一組沒有任何關係的對象都有相同的約束，則可使用抽象工廠模式。在不少軟件系統中須要更換界面主題，要求界面中的按鈕、文本框、背景色等一塊兒發生改變時，涉及不一樣操做系統，可使用抽象工廠模式進行設計。

 

第10章 模板方法模式

1. 定義：定義一個操做中的算法的框架，而將一些步驟延遲到子類中。使得子類能夠不改變一個算法的結構便可重定義該算法的某些特定步驟。
1. 基本方法：就是基本操做，是有子類實現的方法，而且在模板方法中被調用。
2. 模板方法：能夠有一個或幾個，實現對基本方法的調度，完成固定邏輯。

 

4. 優勢：
1. 封裝不變部分，擴展可變部分
2. 提取公共部分代碼，便於維護
3. 行爲有父類控制，子類實現
5. 缺點：若是具體實現過多，須要開發人員話時間去理清關係。
6. 應用場景：
1. 多個子類有公有方法，而且邏輯基本相同
2. 重要、複雜的算法，能夠把核心算法設計爲模板方法，周邊則有子類實現
3. .NET中重寫控件事件就是模板方法模式
7. 擴展：能夠設置一個鉤子方法，從而使子類控制流程走向。

 

第11章 建造者模式（建立型模式）

1. 定義：也叫生成器模式，將一個複雜對象的構建與它的表示分離，使得一樣的構建過程能夠建立不一樣的表示，如製造汽車須要發動機、輪胎。
3. 構成角色：
1. Product產品類：一般是實現了模板方法模式，有模板方法和基本方法。
2. Builder抽象建造者：規範產品的組建，通常是由子類實現。
3. ConcreteBuilder具體建造者：實現抽象類定義的全部方法，而且返回一個組建好的對象。
4. Director導演類：負責安排已有模塊的順序，而後告訴Builder開始建造。
4. 優勢：
1. 封裝性，客戶端不用關心產品內部組成的細節。
2. 建造者獨立，容易擴展。
3. 便於控制細節風險，由於建造者是獨立的，所以可對建造過程細化。
5. 應用場景：
1. 相同方法，不一樣執行順序，產生不一樣的事件結果。
2. 多個部件，均可以裝配到一個對象，但產生結果不一樣時。
3. 產品類很是複雜，或者產品類中的調用順序不一樣產生了不一樣的效能。
6. 建造者模式關注的是零件類型和裝配順序，這是與工廠方法模式的最大不一樣地方。

 

第12章 代理模式（結構型模式）

1. 定義：爲其餘對象提供一種代理以控制這個對象的訪問，並由代理對象控制對原對象的引用。
3. 優勢：
1. 職責清晰，下降耦合，真實角色只關心本身業務邏輯，不用關心相關但非本職的事務，都經過後期代理完成。
2. 高擴展性，保護目標對象，真實角色可隨時發生變化，但依賴接口，因此代理類可不作任何修改。
4. 缺點：
1. 形成請求速度變慢。
2. 代理類須要額外工做，增長系統複雜度。
5. 應用場景：
1. 動態代理：AOP面向切面編程就是經過動態代理模式實現的。
2. 遠程代理：遠程調用操做。
3. 保護代理：保護一個對象的訪問，能夠給不一樣用戶提供不一樣權限。
4. 緩衝代理，爲莫以目標操做的結果提供臨時存儲空間，多個客戶端共享。
5. 防火牆代理：保護目標不讓惡意用戶接近。
6. 同步代理：同步化，使幾個用戶能同時使用一個對象而沒有衝突。
7. 智能引用代理，當一個對象被引用時，提供額外的操做。
8. 虛擬代理，若是要建立一個資源消耗大的對象，能夠先建立一個代理表示，等須要時才真正建立。

 

第13章 原型模式（結構型模式）

1. 定義：用原型實例指定建立對象的種類(自身類型)，而且經過拷貝這些原型建立新的對象。
3. 優勢：
1. 性能優良，是在內存中二進制流的拷貝，比直接new一個對象性能好不少。
2. 逃避構造函數約束，這是優勢也是缺點。
4. 應用場景：
1. 資源優化場景，如類初始化須要消化很是多的資源。
2. 性能和安全要求的場景，經過new建立須要很是繁瑣的數據準備或訪問權限。
3. 一個對象多個修改者的場景。
5. 注意：原型模式，構造函數是不會執行的。

 

第14章 中介者模式（行爲型模式）

1. 定義：用一箇中介對象封裝一系列的對象交互，中介者使各對象不須要顯示地相互做用，起到中轉和協調做用，從而使其耦合鬆散，並且可獨立改變他們之間的交互。
3. 組成角色：
1. Mediator抽象中介者角色，定義統一的接口，用於各同事角色之間的通訊。
2. Concrete Mediator具體中介者角色，經過協調各同事角色實現協做行爲，必須依賴各個同事角色。
3. Colleague同事角色，都知道中介者角色，經過中介者協做。
4. 優勢：減小類間依賴，把本來一對多的依賴變成一對一的依賴。
5. 缺點：中介者會膨脹的很大，並且邏輯複雜，同事類越多，中介者就越複雜。
6. 應用場景：類圖中出現了蜘蛛網狀接口，使用中介者模式變成星型結構。
1. MVC框架，Controller就是一箇中介者。
2. 聊天室
7. 最佳實踐：
1. N個對象之間產生了相互依賴關係。
2. 多個對象有依賴關係，可是需求不肯定，採用中介者模式，可下降變動引發的風險。

 

第15章 命令模式（行爲型模式）

1. 定義：將一個請求封裝成一個對象，從而讓你使用不一樣的請求把客戶端參數化，對請求排隊或者記錄請求日誌，能夠提供命令的撤銷和恢復功能。
3. 組成角色：
1. Receive接收者角色，最終執行的方法。
2. Command抽象命令角色，須要執行的全部命令都在這裏生命。
3. Invoker調用者角色，接收到命令，並執行命令。
4. Client客戶角色，發出一個具體的命令並肯定其接受者。
5. ConcreteCommand具體命令角色，定義一個接受者和行爲的弱耦合，負責調用接受者相應方法。
4. 優勢：
1. 新的命令能夠很容易的加入到系統中。
2. 類間解耦，調用者和接收者之間沒有任何依賴關係，調用者只須要調用Command抽象類的execute方法就能夠，不須要知道具體執行者。
3. 可擴展性，Command的子類能夠很是容易的擴展，高層不產生要種的代碼耦合。
4. 能夠比較容易的設計一個命令隊列和組合命令，命令模式能夠結合責任鏈模式，實現命令族解析任務；能夠結合模板方法模式，則可減小Command子類的膨脹問題。
5. 缺點：若是有N個命令，則須要建立N個Command子類。
6. 應用場景：
1. 系統須要支持命令的撤銷。
2. 系統須要在不一樣的時間指定請求、將請求排隊。
3. 若是系統須要將全部操做記錄日誌，以便崩潰時從日誌恢復。
4. 若是須要執行回調。

 

第16章 責任鏈模式

1. 定義：使多個對象都有機會處理請求，從而避免了請求的發送者和接受者之間的耦合關係。將這些對象連成一條鏈，並沿着這條鏈傳遞該請求，知道有對象處理它爲止。
3. 涉及角色：
1. Handler抽象處理者角色，定義一個處理請求的接口。
2. ConcreteHandler具體處理者角色，具體處理者接受到請求後，能夠選擇處理，或傳給下一個處理者。
4. 抽象處理者二個職責：
1. 定義一個請求的處理方法handleMessage，是惟一對外開放的方法；
2. 定義一個鏈的編排屬性setNext，設置下一個處理者；
5. 具體處理者涉及兩個類：Request類負責封裝請求，Response負責封裝鏈中返回的結果。
6. 優勢：將請求和處理分開，雙方可互不相識，二者解耦，提升系統靈活性。
7. 缺點：
1. 性能問題，每一個請求都是從鏈頭遍歷到鏈尾。
2. 調試不方便，採用了相似遞歸的方式，調試的時候邏輯可能比較複雜。
8. 應用場景：
1. 一個系統的審批須要多個對象才能完成處理的狀況下，例如請假系統。
2. 代碼中存在多個if-else語句的狀況下，能夠考慮使用責任鏈模式來對代碼進行重構。

 

第17章 裝飾模式（結構型模式）

1. 定義：動態的給一個對象添加一些額外的職責，就增長功能來講，裝飾模式相比生成子類更加靈活。

3.  涉及角色：
1. Component抽象構件，是一個接口或抽象類，定義最核心的對象，也就是最原始的對象。
2. ConcreteComponent具體構件，要裝飾的對象。
3. Decorator抽象裝飾角色，有一個執行抽象構件的屬性，若只有一個裝飾類則無需此類。
4. ConcreteDecorator具體裝飾角色，負責對原始對象進行裝飾。

4. 優勢：
1. 裝飾類和被裝飾類能夠獨立發展，而不會互相耦合。
2. 裝飾模式是繼承關係的一個替代方案。
3. 裝飾模式能夠動態地擴展一個實現類的功能。
4. 能夠經過不一樣裝飾類，建立出不一樣的組合。
5. 缺點：多層裝飾提升了系統的複雜度。
6. 應用場景：
1. 須要擴展一個類的功能，或者給一個類增長附加功能。
2. 須要動態給一個對象增長功能，這些功能能夠再動態地撤銷。
3. 須要爲一批的兄弟類進行改裝或加裝功能，首選裝飾模式。

 

第18章 策略模式（行爲型模式）

1. 定義：也叫政策模式，定義一組算法，將每一個算法都封裝起來，而且使它們之間能夠互換。
3. 涉及角色：
1. Context封裝角色，也叫上下文角色，承上啓下，屏蔽高層模塊對策略、算法的直接訪問，封裝可能存在的變化。
2. Strategy抽象策略角色，定義每一個策略或算法必須具備的方法和屬性的接口。
3. ConcreteStrategy具體策略角色，實現抽象策略的操做，含有具體算法。
4. 和代理模式區別，在於Context封裝角色和被封裝的策略類不是用的同一個接口。
5. 優勢：
1. 算法能夠自由切換。
2. 避免使用多重條件判斷。
3. 擴展性良好，如List<T>中IComparer實現排序同樣，可輕鬆增長一個策略，其餘都不用修改。
6. 缺點：
1. 策略類數量增多。
2. 全部的策略類都須要對外暴露。
7. 應用場景：
1. 多個類只有在算法或行爲上稍有不一樣的場景。
2. 算法須要自由切換的場景，如常常變化的業務場景。
3. 須要屏蔽算法規則的場景。

 

第19章 適配器模式（結構型模式）

1. 定義：將一個類的接口變換成客戶端所期待的另外一種接口，從而使本來因接口不匹配而沒法在一塊兒工做的兩個類可以在一塊兒工做。
1. 又叫作變壓器模式，也叫作包裝模式。
2. 涉及角色：
1. Target目標角色，該角色定義把其餘類轉換爲什麼種接口，也就是咱們指望接口。
2. Adaptee源角色，被轉換的類。
3. Adapter適配器角色，經過繼承或類關聯的方式，把源角色轉換爲目標角色。
3. 優勢：
1. 可讓兩個沒有任何關係的類在一塊兒運行。
2. 增長了類的透明性
3. 提升了類的複用度
4. 靈活性好，想用就用不想用就卸載。
4. 缺點：採用了多繼承，帶來了高耦合。
5. 應用場景：有動機修改一個已經投產中的接口時，適配器模式可能就是最合適的。
6. 適配器模式是提供給正在運行的項目使用，項目設計時不要考慮。
7. 對象是適配器，和類適配器的區別是，類適配器是類間繼承，對象適配器是對象的合成關係，也就是關聯關係。

 

第20章 迭代器模式

1. 定義：它提供一種方法訪問一個容器對象中各個元素，而又不需暴露該對象的內部細節。
2. 組成角色
1. Iterator抽象迭代器：負責定義訪問和遍歷元素的接口。
2. ConcreteIterator具體迭代器：實現迭代器接口，完成元素遍歷。
3. Aggregate抽象容器：容器角色負責提供建立具體迭代器角色的接口。
4. ConcreteAggregate具體容器：實現容器接口，建立出容納迭代器的對象。

 

第21章 組合模式

1. 定義：合成模式，部分總體模式，將對象組合成樹形結構表示部分總體的層次結構，使得用戶對單個對象和組合對象的使用具備一致性。
2. 組成角色：
1. Component抽象構件角色，定義參加組合對象的共有方法和屬性，能夠定義一些默認的行爲或屬性。
2. Leaf葉子構件，葉子對象，其下再也沒有其餘的分支，也就是遍歷的最小單位。
3. Composite樹枝構件，它的做用是組合樹枝節點和葉子節點造成一個樹形結構。
3. 優勢，高層模塊調用簡單，節點自由增長。
4. 缺點，直接使用實現類，違法依賴倒置原則。
5. 使用場景：
1. 維護和展現部分-總體關係的場景，如樹形菜單、文件和文件夾管理。
2. 從一個總體中可以獨立出部分模塊或功能的場景。
6. 注意，只要是樹形結構，就能夠考慮組合模式。

 

第22章 觀察者模式

1. 定義：也叫發佈訂閱模式，定義對象間一種一對多的依賴關係，使得每當一個對象改變狀態，則全部依賴於它的對象都會獲得通知並被自動更新。
2. 組成角色：
1. Subject抽象被觀察者，定義必須實現的職責，必須可以動態增長、取消觀察者。並通知觀察者。
2. Observer抽象觀察者，觀察者收到消息後，進行update操做，對接收到的信息進行處理。
3. ConcreteSubject具體被觀察者，定義本身的業務邏輯，同時定義對哪些事件進行通知。
4. ConcreteObserver具體觀察者，每一個觀察者在接收到消息後的處理反應是不一樣的，有各自處理方法。
3. 優勢：
1. 觀察者和被觀察者之間是抽象耦合
2. 創建一套觸發機制，符合單一職責原則。
4. 缺點：多個觀察者，開發和調試負責，一個卡殼會影響總體執行效率。
5. 應用場景：
1. 關聯行爲場景，關聯行爲是可拆分的。
2. 事件多級觸發場景。
3. 跨系統的消息交換場景，如消息隊列的處理機制。
6. 注意：
1. 廣播鏈問題，多級關聯
2. 異步處理，若是處理時間較長，可使用異步
7. 最佳實踐：
1. 文件系統，新增文件通知目錄管理器增長該目錄
2. 廣播收音機，電臺是被觀察者，收音機是觀察者。

 

第23章 門面模式

1. 定義：也叫外觀模式，要求一個子系統的外部與其內部的通訊必須經過一個統一的對象進行，門面模式提供一個高層次的接口，使得子系統更易於使用。
2. 組成角色：
1. Facade門面角色，客戶端調用這個角色，此角色知曉子系統全部的功能和責任。無實際業務邏輯，只作跳板。
2. SubSystem子系統角色，能夠同時又一個或者多個子系統，對於子系統門面角色只是另一個客戶端而已。
3. 優勢：
1. 減小系統的相互依賴，全部的依賴都是對門面對象的依賴，與子系統無關。
2. 提升了靈活性，無論內部如何變化，只要不影響門面對象，任你自由活動。
3. 提升安全性，只能訪問門面角色內的方法。
4. 缺點：不符合開閉原則
5. 使用場景：
1. 爲一個複雜的模塊或子系統提供一個供外界訪問的接口
2. 子系統相對獨立的狀況，外界對子系統的訪問只要黑箱操做便可
6. 通常一個系統只須要一個門面，若是超過200行建議拆成多個門面
7. 門面角色中不能有任何分支邏輯、順尋執行邏輯不然會引子系統必須依賴門面才能被訪問的問題。

 

第24章 備忘錄模式

1. 定義：在不破壞封裝性的前提下，捕獲一個對象的內部狀態，並在該對象以外保存，使對象可恢復到原來保存的狀態。
2. 組成角色：
1. Originator發起人角色，負責建立和恢復備忘錄數據。
2. Memento備忘錄角色，負責存儲Originator發起人角色內部狀態。
3. Caretaker備忘錄管理員角色，對備忘錄進行保存、管理和提供備忘錄。
3. 使用場景：
1. 須要保存和恢復數據的相關狀態場景。
2. 提供一個可回滾的操做，如CTRL+Z。
4. 擴展：
1. 可使用clone實現對自身狀態的管理。
2. 可使用反射實現類下全部屬性的狀態管理。
3. 使用列表管理備忘錄，可實現多備份。

 

第25章 訪問者模式

1. 定義：封裝一些做用於某種數據結構中的各元素的操做，它能夠在不改變數據結構的前提下定義做用於這些元素的新的操做。
2. 組成角色：
1. Visitor抽象訪問者，抽象類或接口，聲明訪問者能夠訪問哪些元素，就是方法接收的參數。
2. ConcreteVisitor具體訪問者，實現訪問者訪問到一個類後幹什麼。
3. Element抽象元素，聲明接受哪一類訪問者訪問，程序上是經過accept方法中的參數來定義的。
4. ObectStruture結構對象，元素產生者，通常容納在多個不一樣類、不一樣接口，如List、Set、Map，項目中通常不多抽象出這個角色。
3. 優勢：
1. 符合單一職責原則
2. 優秀擴展性
3. 靈活性高，好比針對不一樣對象，不一樣處理，能夠不適用if
4. 缺點：
1. 具體元素對訪問者公佈細節
2. 具體元素變動比較困難
3. 違背了依賴倒置原則，訪問者依賴的是具體元素，而不是抽象元素。
5. 應用場景：須要對一個對象結構中的對象進行不少不一樣而且不相關的操做。

 

第26章 狀態模式

1. 定義：當一個對象內在狀態改變時容許其改變行爲，這個對象看起來像改變了它的類。
2. 組成角色：
1. State抽象狀態角色：負責對狀態定義，而且封裝環境角色以實現狀態切換。
2. ConcreteState具體狀態角色：必須有2個職責，本狀態下要作的事，和本狀態如何過渡到其餘狀態。
3. Context環境角色：定義客戶端須要的接口，而且負責具體狀態的切換。
3. 優勢：結構清晰、遵循設計原則、封裝性好
4. 缺點：子類會不少。
5. 應用場景：
1. 行爲隨狀態改變而改變的場景，如權限設計，不一樣人，不一樣結果。
2. 條件、分支判斷語句的替代者。

 

第27章 解析器模式

1. 定義：給定一門語言，定義它的文法的一種表示，並定義一個解釋器，該解釋器使用該表示來解釋語言中的句子。
2. 使用場景：
1. 重複發生的問題可使用解釋器模式，如收集不一樣格式日誌。

 

第28章 亨元模式

1. 定義：使用共享對象可有效地支持大量的細粒度的對象。創建對象池。
2. 組成角色：
1. Flyweight抽象亨元角色，一個產品的抽象類，定義出對象的外部狀態和內部狀態的接口或實現。
2. ConcreteFlyweight具體亨元角色，產品類，不能同時修改內部狀態，外部狀態。
3. unsharedConcreteFlyweight不可共享的亨元角色，通常不會出如今亨元工廠中。
4. FlyweightFactory亨元工廠，構造一個池容器，同時提供從池中得到對象的方法。
3. 優缺點：大大減小應用程序建立的對象，下降內存佔用，加強性能，同時提升了系統複雜性，須要分離外部內部狀態，且外部狀態固化。
4. 應用場景：
1. 系統中存在大量類似對象
2. 須要緩衝池的場景

 

第29章 橋樑模式

1. 定義：也叫橋接模式，將抽象和實現解耦，使得二者能夠獨立地變化。
2. 組成角色：
1. Abstraction抽象化角色，定義出該角色的行爲，同時保存一個實現化角色的引用，通常是抽象類。
2. Implementor實現化角色，它是接口或者抽象類，定義角色必須的行爲和屬性。
3. RefinedAbstraction修正抽象化角色，引用實現化角色對抽象化角色進行修正。
4. ConcreteImplementor具體實現化角色，它實現接口或抽象類定義的方法和屬性。
3. 抽象角色引用實現角色，或者說抽象角色的部分實現是由實現角色完成的
1. 儘可能把最可能的變化封裝到最小的邏輯單元，若是有多層繼承，則考慮橋樑模式。
2. 就像遙控器不包含開機、換臺功能，只包含對電視機功能描述的接口引用，實現是有電視機完成。
4. 優勢：
1. 抽象實現分離，爲了解決繼承的缺點而提出的設計模式，該模式下實現能夠不受抽象的約束。
2. 優秀的擴充能力。
3. 實現細節對客戶透明，客戶不用關心實現細節。
5. 應用場景：
1. 不但願或不適用使用繼承的場景
2. 接口或抽象類不穩定的場景
3. 重用性要求較高的場景