簡介

世界上本沒有路，走的人多了也就成了路；世界上本來沒有設計模式。用的人多了，也就成了設計模式。所以，我們不是嚴格按照它的定義去執行，可以根據自己的實際場景、需求去變通。領悟了其中的思想，實現屬於自己的設計模式。通過對設計模式理解，讓它它慢慢地影響你寫代碼的思維方式；

我們為什麽要使用設計模式？使用設計模式是為了可重用代碼，讓代碼容易被他人理解、保證代碼可靠性以及可維護性。

最近看了一些關於設計模式的文章，以前也實際用過一些，這裏希望將設計模式系列做一下總結，幫助我更深入地理解設計模式；

設計模式導航

創建型

C#設計模式(1)——單例模式

C#設計模式(2)——簡單工廠模式

C#設計模式(3)——工廠方法模式

　 C#設計模式(4)——抽象工廠模式

　 C#設計模式(5)——建造者模式（Builder Pattern）

　 C#設計模式(6)——原型模式（Prototype Pattern）

結構型

　 C#設計模式(7)——適配器模式（Adapter Pattern）

　 C#設計模式(8)——橋接模式（Bridge Pattern）

　 C#設計模式(9)——裝飾者模式（Decorator Pattern）

　 C#設計模式(10)——組合模式（Composite Pattern）

　 C#設計模式(11)——外觀模式（Facade Pattern）

　 C#設計模式(12)——享元模式（Flyweight Pattern）

　 C#設計模式(13)——代理模式（Proxy Pattern）

行為型

　 C#設計模式(14)——模板方法模式（Template Method）

　 C#設計模式(15)——命令模式（Command Pattern）

　 C#設計模式(16)——叠代器模式（Iterator Pattern）

　 C#設計模式(17)——觀察者模式（Observer Pattern）

　 C#設計模式(18)——中介者模式（Mediator Pattern）

　 C#設計模式(19)——狀態者模式（State Pattern）

　 C#設計模式(20)——策略者模式（Stragety Pattern）

　 C#設計模式(21)——責任鏈模式

　 C#設計模式(22)——訪問者模式（Vistor Pattern）

　 C#設計模式(23)——備忘錄模式（Memento Pattern）

設計模式分類

創建型模式

創建型模式就是用來創建對象的模式，抽象了實例化的過程。所有的創建型模式都有兩個共同點。第一，它們都將系統使用哪些具體類的信息封裝起來；第二，它們隱藏了這些類的實例是如何被創建和組織的。創建型模式包括單例模式、工廠方法模式、抽象工廠模式、建造者模式和原型模式。

• 單例模式：解決的是實例化對象的個數的問題，比如抽象工廠中的工廠、對象池等，除了Singleton之外，其他創建型模式解決的都是 new 所帶來的耦合關系。
• 抽象工廠：創建一系列相互依賴對象，並能在運行時改變系列。
• 工廠方法：創建單個對象，在Abstract Factory有使用到。
• 原型模式：通過拷貝原型來創建新的對象。

　　工廠方法，抽象工廠, 建造者都需要一個額外的工廠類來負責實例化“一個對象”，而Prototype則是通過原型（一個特殊的工廠類）來克隆“易變對象”。

結構型模式

　結構型模式，顧名思義討論的是類和對象的結構 ，主要用來處理類或對象的組合。它包括兩種類型，一是類結構型模式，指的是采用繼承機制來組合接口或實現；二是對象結構型模式，指的是通過組合對象的方式來實現新的功能。它包括適配器模式、橋接模式、裝飾者模式、組合模式、外觀模式、享元模式和代理模式。

• 適配器模式註重轉換接口，將不吻合的接口適配對接
• 橋接模式註重分離接口與其實現，支持多維度變化
• 組合模式註重統一接口，將“一對多”的關系轉化為“一對一”的關系
• 裝飾者模式註重穩定接口，在此前提下為對象擴展功能
• 外觀模式註重簡化接口，簡化組件系統與外部客戶程序的依賴關系
• 享元模式註重保留接口，在內部使用共享技術對對象存儲進行優化
• 代理模式註重假借接口，增加間接層來實現靈活控制

行為型模式

行為型模式是對在不同對象之間劃分責任和算法的抽象化。行為模式不僅僅關於類和對象，還關於它們之間的相互作用。行為型模式又分為類的行為模式和對象的行為模式兩種。

• 類的行為模式——使用繼承關系在幾個類之間分配行為。
• 對象的行為模式——使用對象聚合的方式來分配行為。

　　行為型模式包括11種模式：模板方法模式、命令模式、叠代器模式、觀察者模式、中介者模式、狀態模式、策略模式、責任鏈模式、訪問者模式、解釋器模式和備忘錄模式。

• 模板方法模式：封裝算法結構，定義算法骨架，支持算法子步驟變化。
• 命令模式：註重將請求封裝為對象，支持請求的變化，通過將一組行為抽象為對象，實現行為請求者和行為實現者之間的解耦。
• 叠代器模式：註重封裝特定領域變化，支持集合的變化，屏蔽集合對象內部復雜結構，提供客戶程序對它的透明遍歷。
• 觀察者模式：註重封裝對象通知，支持通信對象的變化，實現對象狀態改變，通知依賴它的對象並更新。
• 中介者模式：註重封裝對象間的交互，通過封裝一系列對象之間的復雜交互，使他們不需要顯式相互引用，實現解耦。
• 狀態模式：註重封裝與狀態相關的行為，支持狀態的變化，通過封裝對象狀態，從而在其內部狀態改變時改變它的行為。
• 策略模式：註重封裝算法，支持算法的變化，通過封裝一系列算法，從而可以隨時獨立於客戶替換算法。
• 責任鏈模式：註重封裝對象責任，支持責任的變化，通過動態構建職責鏈，實現事務處理。
• 訪問者模式：註重封裝對象操作變化，支持在運行時為類結構添加新的操作，在類層次結構中，在不改變各類的前提下定義作用於這些類實例的新的操作。
• 備忘錄模式：註重封裝對象狀態變化，支持狀態保存、恢復。
• 解釋器模式：註重封裝特定領域變化，支持領域問題的頻繁變化，將特定領域的問題表達為某種語法規則下的句子，然後構建一個解釋器來解釋這樣的句子，從而達到解決問題的目的。

設計原則

　　使用設計模式的根本原因是適應變化，提高代碼復用率，使軟件更具有可維護性和可擴展性。並且，在進行設計的時候，也需要遵循以下幾個原則：單一職責原則、開放封閉原則、裏氏代替原則、依賴倒置原則、接口隔離原則、合成復用原則和迪米特法則。下面就分別介紹了每種設計原則。

單一職責原則

　　就一個類而言，應該只有一個引起它變化的原因。如果一個類承擔的職責過多，就等於把這些職責耦合在一起，一個職責的變化可能會影響到其他的職責，另外，把多個職責耦合在一起，也會影響復用性。

開閉原則(Open-Closed Principle)

　　開閉原則即OCP（Open-Closed Principle縮寫）原則，該原則強調的是：一個軟件實體（指的類、函數、模塊等）應該對擴展開放，對修改關閉。即每次發生變化時，要通過添加新的代碼來增強現有類型的行為，而不是修改原有的代碼。

裏氏代替原則(Liskov Substitution Principle)

　　Liskov Substitution Principle,LSP（裏氏代替原則）指的是子類必須替換掉它們的父類型。也就是說，在軟件開發過程中，子類替換父類後，程序的行為是一樣的。只有當子類替換掉父類後，此時軟件的功能不受影響時，父類才能真正地被復用，而子類也可以在父類的基礎上添加新的行為。

依賴倒置原則

　　依賴倒置（Dependence Inversion Principle, DIP）原則指的是抽象不應該依賴於細節，細節應該依賴於抽象，也就是提出的 “面向接口編程，而不是面向實現編程”。這樣可以降低客戶與具體實現的耦合。

接口隔離原則

　　接口隔離原則（Interface Segregation Principle, ISP）指的是使用多個專門的接口比使用單一的總接口要好。也就是說不要讓一個單一的接口承擔過多的職責，而應把每個職責分離到多個專門的接口中，進行接口分離。過於臃腫的接口是對接口的一種汙染。

合成復用原則

　　合成復用原則（Composite Reuse Principle, CRP）就是在一個新的對象裏面使用一些已有的對象，使之成為新對象的一部分。新對象通過向這些對象的委派達到復用已用功能的目的。簡單地說，就是要盡量使用合成/聚合，盡量不要使用繼承。

　　要使用好合成復用原則，首先需要區分"Has—A"和“Is—A”的關系。

　　“Is—A”是指一個類是另一個類的“一種”，是屬於的關系，而“Has—A”則不同，它表示某一個角色具有某一項責任。導致錯誤的使用繼承而不是聚合的常見的原因是錯誤地把“Has—A”當成“Is—A”.

迪米特法則

　　迪米特法則（Law of Demeter，LoD）又叫最少知識原則（Least Knowledge Principle，LKP），指的是一個對象應當對其他對象有盡可能少的了解。也就是說，一個模塊或對象應盡量少的與其他實體之間發生相互作用，使得系統功能模塊相對獨立，這樣當一個模塊修改時，影響的模塊就會越少，擴展起來更加容易。

　　關於迪米特法則其他的一些表述有：只與你直接的朋友們通信；不要跟“陌生人”說話。

　　外觀模式（Facade Pattern)和中介者模式（Mediator Pattern）就使用了迪米特法則。

參考：

http://www.cnblogs.com/mjq5150/p/6273341.html

C#設計模式(0)-認識設計模式