設計模式適用場景整理

整理一下適用場景，便於遇到合適場景時通過使用設計模式更好地去掌握設計模式

設計模式分建立型、行為型、結構型

建立型

策略模式：某一個功能有多種方案可以選擇的情景
單例模式：建立獨一無二的，只能有一個例項的物件；一個無狀態的類，使用該模式節省資源
工廠模式：建立新物件，且該物件需要被被封裝
抽象工廠模式：用於建立一組產品（各產品不一定相同）
建造模式：一個類的各個組成部分的具體實現類或者演算法經常面臨著變化，但是將他們組合在一起的演算法卻相對穩定。提供一種封裝機制 將穩定的組合演算法於易變的各個組成部分隔離開來。
原型模式：用new建立一個物件需要非常繁瑣的資料準備或者許可權

行為型

模板模式：架構師用於搭建專案的框架，架構師定好了骨架，程式設計師繼承了骨架的結構之後，負責往裡面填空
命令模式：向某些物件傳送請求，但是並不知道請求的接受者是誰，也不知道請求的操作是什麼；讓程式執行的任何時刻去呼叫這個方法；
將一個請求封裝為一個物件，從而使你可以用不同的請求對客戶進行引數化
迭代器模式：需要順序訪問一個組合內的多個物件的時候使用。
觀察者模式：非同步程式設計；主題是具有狀態的物件，並且可以控制這些狀態，觀察者使用這些狀態，雖然這些狀態不屬於它們
狀態模式：一個物件的行為取決於它的狀態，並且它必須在執行時刻根據狀態改變它的行為；個操作中含有龐大的多分支結構，並且這些分支決定於物件的狀態
職責鏈模式：使多個物件都有機會處理請求，從而避免請求的送發者和接收者之間的耦合關係
中介者模式：用一箇中介物件封裝一些列的物件互動
訪問者模式：表示一個作用於某物件結構中的各元素的操作，它使你可以在不改變各元素類的前提下定義作用於這個元素的新操作
備忘錄模式：在不破壞物件的前提下，捕獲一個物件的內部狀態，並在該物件之外儲存這個狀態

結構型

裝飾者模式：增加行為到包裝物件上，在不改變物件自身的基礎上，在程式執行期間給物件動態的新增職責
代理模式：為另一個物件提供一個替身或佔位符以控制對這個物件的訪問
外觀模式：子系統中的一組介面提供一致的介面
介面卡模式：將一類的介面轉換成客戶希望的另外一個介面；使得原本由於介面不相容而不能一起工作那些類可以一起工作
橋樑模式：將抽象部分與它的實現部分相分離，使他們可以獨立的變化
組合模式：將物件組合成樹形結構以表示部分整體的關係；使得使用者對單個物件和組合物件的使用具有一致性
享元模式：
享元模式以共享的方式高效的支援大量的細粒度物件。享元模式能做到共享的關鍵是區分內蘊狀態和外蘊狀態。內蘊狀態儲存在享元內部，不會隨環境的改變而有所不同。外蘊狀態是隨環境的改變而改變的。