常用設計模式小結
- 2019 年 12 月 26 日
- 筆記
現在你已經準備好迎接一個充滿設計模式的嶄新世界。 但是，在你打開所有的機會大門之前，我們需要告訴你一些即將在真實世界中遇到的細節–沒錯，外面的世界還是比較複雜的。來吧，接下來，我們會指引你的方向……
定義設計模式
在看完之前這麼多章節的系列，相信作為讀者的你已經基本了解什麼是設計模式了。但我們至今還未給它一個正式的定義。我們先拿出一個常用的定義：
模式：是在某情境下，針對某問題的某種解決方案。 情境就是應用某個模式的情況。這應該是會不斷出現的情況。（例如：你擁有一個對象的集合） 問題就是你想在某情境下達到的目標 ，但也可以是某情境下的約束。（你需要注意走訪每個對象，而且不需理會該集合的實現） 解決方案就是你所追求的：一個通用的設計，用來解決約束、達到目標。（將迭代封裝進分離的類中）
這是一個需要花些時間逐步理解的定義。在這裡，我幫你們找到了一個記憶的方法：
「如果你發現自己處於某個情境下，面對着所欲達到的目標被一群約束影響着的問題，然後，你能夠應用某個設計，克服這些約束並達到該目標，將你領向某個解決方案。」
組織設計模式
對着發掘的設計模式數目逐漸增加，有必要將他們分門別類，好將他們組織起來，以簡化我們尋找模式的過程，並讓同一群組內的模式互相比較。
我們感覺模式的目標分成三個不同類目：創建型、行為型和結構型。
小編先來引導下，這三個類型的基本定義。
創建型模式涉及到將對象實例化，這類模式都提供一個方法，將客戶從所需要實例化的對象中解耦。
行為型模式涉及到類和對象如何交互及分配職責。
結構型模式可以讓你把類或對象組合到更大的結構中。
現在有了基本的定義，請先停頓下，給自己幾分鐘時間來給設計模式分類，然後再看下面小編整理的分類。
|
|
|
|
|---|---|---|
|
創建型 |
行為型 |
結構型 |
|
單例（singleton） |
模板方法（Template Method） |
裝飾（Decorator） |
|
工廠(Factory Method) |
命令（Command） |
組合（Composite） |
|
抽象工廠（Abstract Factory） |
觀察者（Observer） |
適配器（Adapter） |
|
建造者（Builder） |
迭代器（Iterator） |
代理（Proxy） |
|
原型（Prototype） |
狀態（State） |
外觀（Facede） |
|
|
策略（Strategy） |
享元（Flyweight） |
|
|
中介者（Mediator） |
橋接（Bridge） |
|
|
訪問者（Visitor） |
|
|
|
備忘錄（Memento） |
|
|
|
解釋器（Interpreter） |
|
|
|
責任鏈（Chain of Responsibility） |
|
其中未加粗部分還沒系統學習過，在稍後的章節，還會做一些簡單的介紹。
除了剛才的分類之外 ，模式還有另一種分類方式：模式所處理的類或對象
類模式描述類之間的關係如何通過繼承定義。類模式的關係是在編譯時建立的。
對象模式描述對象之間的關係，而且主要是利用組合定義。對象模式的搞關係通常在運行時建立，而且更加動態、更有彈性。
|
類 |
對象 |
|---|---|
|
模板方法（Template Method） |
單例（singleton） |
|
工廠(Factory Method) |
裝飾（Decorator） |
|
適配器（Adapter） |
命令（Command） |
|
解釋器（Interpreter） |
組合（Composite） |
|
|
抽象工廠（Abstract Factory） |
|
|
觀察者（Observer） |
|
|
建造者（Builder） |
|
|
迭代器（Iterator） |
|
|
代理（Proxy） |
|
|
原型（Prototype） |
|
|
狀態（State） |
|
|
外觀（Facede） |
|
|
策略（Strategy） |
|
|
享元（Flyweight） |
|
|
中介者（Mediator） |
|
|
橋接（Bridge） |
|
|
訪問者（Visitor） |
|
|
備忘錄（Memento） |
|
|
責任鏈（Chain of Responsibility） |
用模式思考問題
小編在這裡根據書本，還整理了一份快速指南，可以幫助你開始「用模式思考」。所謂「用模式思考」，意思就是說，能夠看着設計，體會在什麼地方模式能自然適用，在什麼地方模式則不能。
- 保持簡單
首先，當你設計時，儘可能地用最簡單的方式解決問題。你的目標應該是簡單，而不是「如何在這個問題中應用模式」。如果沒有使用模式解決某個問題，千萬不要以為你就不是一個經驗豐富的開發人員。如果你能保持簡單的設計，那豈不是更好，甚至你還能得到其他開發人員的欣賞和尊敬呢。
所以，正確的做法就是，為了要讓你的設計簡單而且有彈性，有時候使用模式是最好的辦法，但不是每次都需要使用。
- 設計模式非靈丹妙藥
如果所知道的，模式是解決一再發生的問題的通用方案。模式已經被許多開發人員實際測試過。所以，當你需要某個模式的時候，可以放心地使用它，畢竟你知道這個模式已經身經百戰。
然後，模式並非靈丹妙藥。你需要考慮到模式對你的設計中其他部分所造成的後果。
- 你知道何時需要模式
這是最重要的問題：何時使用模式？當你在設計的時候，如果確定在你的設計中可以利用某個模式解決某個問題，那麼就是用這個模式！如果有更簡單的解決方案，那麼在決定是用模式之前應該先考慮這個方案。
如何知道何時是用一個模式，這就需要經驗和知識了。一旦你確定一個簡單的解決方案無法滿足你的需要，應該考慮這個問題以及相關的約束–這可以幫你將問題對應到一個模式中。如果你對模式有很深的認知，就可能知道有什麼模式適合這樣的情況。否則，就花些時間調查一下可能會解決這個問題的模式，模式類目中的意圖和應用部分會特別有用。
- 拿掉你所不需要的
何時應該刪除這個模式呢？當你的系統變得非常複雜，而且並不需要預留任何彈性的時候，就不要使用模式。換句話說，也就是當一個比較簡單的解決方案比使用模式更好的時候，你就不需要使用。
- 如果你現在不需要，就別做
如果你今天在設計中有實際的需要去支持改變，就放手採用模式處理這個改變。但是，如果說理由只是假想的，就不要添加這個模式，因為這隻會將你的系統搞越複雜，而且很可能你永遠都不會需要它。
最後，將模式和描述配對
在這篇文章的最後，還是給大家一個十足的乾貨，將之前所學的設計模式和描述進行配對，讓你對這些常用的模式有一個更加深刻的印象，讓你學習有成。
|
模式 |
描述 |
|---|---|
|
裝飾者 |
包裝一個對象，以提供新的行為 |
|
狀態 |
封裝了基於狀態的行為，並使用委託在行為之間切換 |
|
迭代器 |
在對象的集合之中遊走，而不暴露集合的實現 |
|
外觀 |
簡化一群類的接口 |
|
策略 |
封裝可以互換的行為，並使用委託來決定要使用哪一個 |
|
代理 |
包裝對象，以控制對此對象的訪問 |
|
工廠方法 |
由子類決定要創建的具體類是哪一個 |
|
適配器 |
封裝對象，並提供不同的接口 |
|
觀察者 |
讓對象能夠在狀態改變時被通知 |
|
模板方法 |
由子類決定如何實現一個算法中的步驟 |
|
組合 |
客戶用一致的方式處理對象集合和單個對象 |
|
抽象工廠 |
允許客戶創建對象的家族，而無需指定他們的具體類 |
|
命令 |
封裝請求成為對象 |
小結
至此，《Head First 設計模式》一書，歷時五個月，小編把書中詳細介紹的模式基本都學習並輸出了一遍。其中，第12章有個複合模式，講述的是一個MVC使用設計模式的過程，小編還需要消化，也怕輸出起來影響大家的學習，故就斷了這個念頭。
還有11章的代理模式，小編挑選了Hollis在博客上的文章來學習，力求能讓大家看的更好，小編在此和大家道歉。很感謝，從頭到尾一直和小編學習的讀者，設計模式系列，還有最後的輸出，小編會繼續努力，把這個系列用更好的方式完結。
