設計模式知識梳理(1) 設計模式概述

時間 2019-11-21

標籤設計模式知識梳理概述简体版

原文原文鏈接

1、概述

去年時候看過<<Head First 設計模式>>這本書，也記了一些用例和筆記，下面是當時各模式對應的筆記，如今看起來也都忘的差很少了，就把之前的筆記看成是一個目錄，打算花半個到一個月的時間，好好地總結一下每一個設計模式。算法

2、各設計模式詳解

2.1 策略模式

定義了算族，分別封裝起來，讓它們之間能夠互相替換，此模式讓算法的變化獨立於使用算法的客戶。編程

2.2 觀察者模式

2.3 裝飾者模式

裝飾者對象和被裝飾者對象具備一樣的超類型。
你能夠用一個或多個裝飾者包裝一個對象。
既然裝飾者和被裝飾對象具備一樣的超類型，因此在任何須要原始對象（被包裝的場合），能夠用裝飾過的對象代替它。
裝飾者能夠在所委託被裝飾者的行爲以前與/或以後，加上本身的行爲，以達到特定的目的。
對象能夠在任什麼時候候被裝飾，因此能夠在運行時動態地、不限量地用你喜歡的裝飾者來裝飾對象。

2.4 簡單工廠

簡單工廠其實並非一個設計模式，反而比較像是一種編程習慣。設計模式

2.5 工廠方法模式

定義了一個建立對象的接口，但由子類決定要實例化的類是哪個，工廠方法讓類把實例化推遲到子類。數組

2.6 抽象工廠模式

提供一個接口，用於建立相關或依賴對象的家族，而不須要明確指定具體類。數據結構

2.7 單件模式

確保一個類只有一個實例。設計

2.8 適配器模式

客戶和被適配者是解耦的。
包裝某些對象，讓它們的接口看起來不像本身而像是別的東西，由於這樣就能夠在設計中，將類的接口轉換成想要的接口，以便實現不一樣的接口。
將一個接口轉換成另外一個接口，以符合客戶的指望。
客戶使用適配器的過程：客戶經過目標接口調用適配器的方法對適配器發出請求，適配器使用被適配者接口把請求轉換成被適配者的一個或多個調用接口，客戶接收到調用的結果，但並未發覺這是適配器在起做用。
適配器模式將一個類的接口，轉換成客戶指望的另外一個接口，適配器讓本來接口不兼容的類能夠合做無間。
若是在一段時間以後，咱們想要改變接口，適配器能夠將改變的部分封裝起來，客戶就沒必要爲了應對不一樣的接口而每次跟着修改。
這個適配器模式充滿着良好的OO設計原則：使用對象組合，以修改的接口包裝被適配者，這種作法還有額外的優勢，那就是，被適配者的任何子類，均可以搭配着適配器使用。

2.9 外觀模式

將一個或數個類的複雜的一切都隱藏在背後，只顯出一個乾淨美好的外表。提供了一個統一的接口，用來訪問子系統中的一羣接口，外觀定義了一個高層接口，讓子系統更容易使用。不要贏得太多的朋友和影響太多的對象：就職何對象而言，在該對象的方法內，咱們只應該調用屬於如下範圍的方法：代理

該對象自己。
被當作方法的參數而傳進來的對象。
此方法建立或實例化的任何對象。
對象的任何組件。
若是某對象是調用其它的方法的返回結果，不要調用該對象的方法。

適配器將一個對象包裝起來以改變其接口；裝飾者將一個對象包裝起來以增長新的行爲和責任；外觀將一羣對象「包裝」起來以簡化其接口；code

2.10 模板方法模式

在一個方法中定義一個算法的骨架，而將一些步驟延遲到子類中。模板方法使得子類能夠在不改變算法結構的狀況下，從新定義算法中的某個步驟。對象

Comparator<T>正是使用這種模式達到排序的效果。排序

好萊塢準則：咱們容許低層組件將本身掛鉤到系統上，可是高層組件會決定何時和怎樣使用這些低層組件，高層組件對待低層組件的方式是"別調用咱們，咱們會調用你"

策略模式和模板方法模式都封裝算法，一個用組合，一個用繼承。工廠方法是模板方法的一種特殊版本。

2.11 迭代器模式

提供一種方法順序訪問一個聚合對象中的各個元素，而又不暴露其內部的表示。

若是你有一個統一的方法來訪問聚合中的每個對象，你就能夠編寫多態的代碼和這些聚合搭配，使用。
迭代器模式把在元素之間遊走的責任交給迭代器（createIterator），而不是聚合對象（xxMenu），這不只讓聚合的接口和實現變得更簡潔，也可讓聚合更專一在它所專一的事情上面，而沒必要去理會遍歷的事情。

2.12 組合模式

容許你將兌現組合成樹形結構來表現"總體/部分"層次結構，組合能讓客戶以一致的方式（MenuComponent）處理個別對象以及對象組合。

組合模式讓咱們能用樹形方式建立對象的結構，樹裏面包含了組合以及個別對象。
使用組合結構，咱們能把相同的操做應用在組合和個別對象上，換句話說，在大多數狀況下，咱們能夠忽略對象組合和個別對象之間的差異。
組合以單一責任設計原則換取透明性，經過讓組件的接口同時包含一些管理子節點和葉節點的操做，客戶就能夠將組合和葉節點一視同仁，也就是說，一個元素到底是組合仍是葉節點，對客戶是透明的。

咱們應該努力讓一個類只分配一個責任。

2.13 狀態模式

（狀態 -> 類，行爲 -> 方法）

將每一個狀態的行爲都放在各自的類中，那麼每一個狀態只要實現它本身的動做就能夠了，糖果機只須要委託給表明當前狀態的狀態對象。

首先，定義一個State接口，在這個接口內，糖果機的每一個動做都有一個對應的方法。
而後爲機器中的每一個狀態實現狀態類，這些類將負責在對應的狀態下進行機器的行爲。
最後，咱們要擺脫舊的條件代碼，取而代之的是，將動做委託到狀態類。

Context也能夠決定狀態轉換的流向，狀態轉換是固定的時候，就適合放在Context中，而後，當轉換是更動態的時候，一般就會放在狀態類中。將狀態轉換放在狀態類的缺點是，狀態類之間產生了依賴。

狀態模式容許對象在內部狀態改變時改變它的行爲，對象看起來好像修改了它的類。（經過在Context內簡單地改變狀態對象來改變context的行爲）

2.14 代理模式

爲另外一個對象提供一個替身或佔位符以控制對這個對象的訪問。

在某些狀況下，一個客戶不想或者不能直接引用另外一個對象，而代理對象能夠在客戶端和目標對象之間起到中介的做用。
抽象角色：聲明真實對象和代理對象的共同接口。
代理角色：代理對象角色內部含有對真實對象的引用，從而能夠操做真實對象，同時代理對象提供與真實對象相同的接口以便在任什麼時候刻可以代替真實對象。
真實角色：代理角色所表明的真實對象，是咱們最終要引用的對象。

2.15 橋接模式

經過將實現和抽象放在兩個不一樣的類層次中而使它們能夠獨立地改變。優勢：

將實現予以解耦，讓它和界面之間再也不永久綁定。
抽象和實現能夠獨立擴展，不會影響到對方。
對於"具體的抽象類"所作的改變，不會影響到客戶。用途和缺點：
適合使用在須要跨越多個平臺的圖形和窗口系統上。
當須要用不一樣的方式改變接口和實現時，你會發現橋接模式很好用。
增長了複雜度。

2.16 生成器模式

使用生成器模式封裝一個產品的構造過程，並容許按步驟構造。

2.17 責任鏈模式

當你想要讓一個以上的對象有機會可以處理某個請求的時候，就使用責任鏈模式。

2.18 享元模式

經過使用共享的方式，達到高效地支持大量的細粒度對象。

2.19 解釋器模式

解釋器模式是類的行爲模式，給定一個語言之後，解釋器模式能夠定義出其文法的一種表示，並同時提供一個解釋器，客戶端能夠經過這個解釋器來解釋這個語言中的句子。模式涉及的角色：

抽象表達式：聲明一個全部的具體表達式角色都須要實現的抽象接口。這個接口主要是一個interpret()方法，稱作解釋操做。
終結符表達式：實現了抽象表達式角色所要求的接口，主要是一個interpret()方法；文法中的每個終結符都有一個具體終結表達式與之相對應。好比有一個簡單的公式R=R1+R2，在裏面R1和R2就是終結符，對應的解析R1和R2的解釋器就是終結符表達式。
非終結符表達式：文法中的每一條規則都須要一個具體的非終結符表達式，非終結符表達式通常是文法中的運算符或者其餘關鍵字，好比公式R=R1+R2中，「+"就是非終結符，解析「+」的解釋器就是一個非終結符表達式。（4）環境角色：這個角色的任務通常是用來存放文法中各個終結符所對應的具體值，好比R=R1+R2，咱們給R1賦值100，給R2賦值200。這些信息須要存放到環境角色中，不少狀況下咱們使用Map來充當環境角色就足夠了。