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

標籤：文法   繼承   迭代   comm   依賴關係   解決   領域   訪問者模式   eth   

簡介

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

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

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

設計模式導航

建立型

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

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

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

　 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）

 

設計模式分類建立型模式

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

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

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

結構型模式

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

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

行為型模式

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

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

　　行為型模式包括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)-認識設計模式