設計模式之23種模式：

二、23種設計模式：

dog	bird	定義/概念
foo	簡單工廠模式 Simple Factory Pattern	從設計模式的類型上來說，簡單工廠模式是屬于建立型模式，又叫做靜态工廠方法（StaticFactory Method）模式，但不屬于23種GOF設計模式之一。簡單工廠模式是由一個工廠對象決定建立出哪一種産品類的執行個體。簡單工廠模式是工廠模式家族中最簡單實用的模式，可以了解為是不同工廠模式的一個特殊實作。
bar	政策模式 Strategy Pattern	政策模式(strategy)定義了一系列的算法，并将每一個算法封裝起來，而且使它們還可以互相替換。政策模式讓算法獨立于使用它的客戶而獨立變化。政策模式的組成:1）抽象政策角色： 政策類，通常由一個接口或者抽象類實作。2）具體政策角色：包裝了相關的算法和行為。3）環境角色：持有一個政策類的引用，最終給用戶端調用。
baz	裝飾模式 Decorator Pattern	動态的給一個對象添加一些額外的職責，就增加功能來說，裝飾模式比生成子類更為靈活。總結：把類中裝飾功能從類中搬移去除，這樣可以簡化已有的類；最大好處：有效地把類的核心職責和裝飾功能分開了。而且可以去除重複的裝飾邏輯。
	工廠方法模式 Fatory Method	定義一個用于建立對象的接口，讓子類決定執行個體化哪個類。工廠方法使一個類的執行個體化延遲到其子類。【實作】工廠方法模式實作時，用戶端需要決定執行個體化哪一個工廠來實作運算類，選擇判斷的問題還是存在的，也就是說，工廠方法把簡單工廠的内部邏輯判斷轉移到了用戶端的代碼來進行，你想要加功能，本來改工廠類的，現在是修改用戶端。
	原型模式Prototype Pattern	用原型執行個體指定建立對象的種類，并且通過拷貝這些原型建立新的對象。【白話】原型對象其實就是從一個對象再建立另外一個可定制的對象，而且不需知道任何建立的細節。
	模闆方法模式 Template Method	定義一個操作中的算法的骨架，而将一些步驟延遲到子類中。模闆方法使得子類不改變一個算法的結構即可重定義該算法的某些特定步驟。【白話】：模闆方法模式是通過把不變行為搬移到超類，去除子類中的重複代碼來展現他的優勢。
	外觀模式 Facade Pattern	為子系統中的一組接口提供一個一緻的界面，此模式定義了一個高層接口，這個接口使得這一子系統更加容易使用。
	建造者模式Builder Pattern	将一個複雜對象的建構與它的表示分離，使得同樣的建構過程可以建立不同的表示。【注意：】首先它意圖是要建構一個複雜的對像，而這個複雜的對像往往需要由好幾個子對象或分步驟來完成最終的這個對象的建構，而這個複雜對象的子對像經常需要不斷的變化，但它的建構過程是相對是穩定的。
	觀察者模式釋出-訂閱模式 Publish-Subscribe Pattern	定義了一種一對多的依賴關系，讓多個觀察者對象同時監聽某一個主題對象。這個主題對象在狀态發生變化時，會通知所有觀察者對象，使它們能夠夠自動更新自己。
	抽象工廠模式Abstract Factory Pattern	提供一個建立一系列相關或互相依賴對象的接口，而無需指定他們具體的類。【用途】：用于交換産品系列，如ACCESS->SQL SERVER；産品的具體類名被具體工廠的實作分離。
	狀态模式 State Pattern	當一個對象的内在狀态改變時允許改變其行為，這個對象看起來像是改變了其類。【主要解決】：對象狀态轉換的條件表達式過于複雜的情況。把狀态的判斷邏輯轉移到表示不同狀态的一個類中，可以把複雜的判斷邏輯簡化。
	擴充卡模式Adapter Pattern	将一個類的接口轉換成客戶希望的另外一個接口。Adapter模式使得原來由于接口不相容而不能一起工作的那些類可以一起工作。
	備忘錄模式Memento Pattern	在不破壞封裝性的前提下，捕獲一個對象的内部狀态，并在該對象之外儲存這個狀态。這樣以後就可将該對象恢複到原來儲存的狀态。
	組合模式Composite Pattern	将對象組合成樹形結構以表示‘部分-整體’的層次結構。組合模式使得使用者對單個對象群組合對象的使用具有一緻性。【使用時機】：當發現需求中是展現部分與整體層次的結構時，以及你希望使用者可以忽略組合對象與單個對象的不同，統一地使用組合結構中的所有對象時，就應該考慮用組合模式。
	單例模式singleton Pattern	保證一個類僅有一個執行個體，并提供一個通路它的全局通路點。【解釋】：因為Singleton類封裝它的唯一執行個體，這樣它可以嚴格地控制客戶怎麼通路它以及何時通路它。簡單的說就是對唯一執行個體的受控通路。
	橋接模式 Bridge Pattern	将抽象部分與它的實作部分分離，使它們都可以獨立地變化。【解釋】：實作系統可能有多角度分類，每一種分類都有可能變化，那麼就把這種多角度分離出來讓他們獨立變化，減少他們之間的耦合。
	指令模式Command Pattern	将一個請求封裝成一個對象，進而使你可用不同的請求對客戶進行參數化；對請求排隊或記錄請求日志，以及支援可撤銷的操作。
	職責鍊模式 Chain of Responsibility Pattern	使多個對象都有機會處理請求，進而避免請求的發送者和接受者之間的耦合關系。将這個對象連成一個鍊，并沿着這條鍊傳遞該請求，直到有一個對象處理它為止。【關鍵】:當客戶送出一個請求後，請求是沿着鍊傳遞直至有一個ConcreteHandler對象負責處理它。
	中介者模式Mediator Pattern	用一個中介對象來封裝一系列的對象互動。中介者使各對象不需要顯式的互相引用，進而使耦合松散，而且可以獨立的改變他們之間的互動。【應用場景】：一組對象已定義良好但是需要複雜的方式進行通信的場合，以及想定制一個分布在多個類中的行為，而又不想生成太多的子類的場合。
	享元模式FlyWeight Pattern	運用這種技術可有效地支援大量粒度的對象。【使用場合】：可以避免大量相似類的開銷。對于C++來說就是共用一個記憶體塊啦，對象指針指向同一個地方。如果一個應用程式使用了大量的對象，而這些對象造成了很大的存儲開銷就應該考慮使用。還有就是對象的大多數狀态可以外部狀态，如果删除對象的外部狀态，那麼可以用較少的共享對象取代多組對象，此時可以考慮使用享元。
	解釋器模式Interpreter Pattern	給定一個語言，定義它的文法的一種表示，并定義一個解釋器，這個解釋器使用該表示來解釋語言中的句子。【使用】：如果一個特定問題發生的頻率足夠高，那麼可能就值得将該問題的各個執行個體表述為一個簡單語言中的句子。這樣就可以建構一個解釋器，該解釋器通過解釋這些句子來解決該問題。
	通路者模式Visitor Pattern	表示一個作用于某對象結構中的各元素的操作，它使你可以在不改變各元素的類的前提下定義作用于這些元素的新操作。【優點】：增加新的操作很容易，因為增加新的操作意味着增加一個新的通路者。通路者的模式将有關的行為集中在一個通路者對象中。【缺點】：增加新的資料結構變得很困難。

___大部分内容摘自《大話設計模式》

個人感覺：

1.可能剛開始看每個設計模式的時候，通過執行個體能知道其應用原理？但是當多個模式一起的時候，比如：擴充卡模式、橋接模式、中介者模式的差別？可能就不是很快的說清楚（當然也說明自己沒有徹底領悟，另一個方面說明了自己沒有用過相關的設計模式。

2.在實踐中如果應用了設計模式才能真正感覺她的妙處，這也是我所欠缺的。

作者：銘毅天下

原文：

https://blog.csdn.net/laoyang360/article/details/8066571