設計模式學習（一）：從設計原則到設計模式

說明：這些資料僅僅是對設計模式的一些總結，沒有設計模式的相關知識，很難看懂。即使看懂了這些，也僅說明了解了模式的基本思想。想要學好設計模式，還是建議好好看文後所列的參考書籍和推薦書籍。

　　這些總結有不少是根據自己的了解寫成的，或許并不正确。如果您有不同的看法，請告知作者，謝謝！

　　歡迎傳閱，但是請勿随意修改或Copy。

　　每一個模式描述了一個在我們周圍不斷重複發生的問題，以及該問題的解決方案的核心。                                    

                                                                                      -- Christopher Alexander

　　設計模式描述了軟體設計過程中某一類常見問題的一般性的解決方案。面向對象設計模式描述了面向對象設計過程中,特定場景下，類(抽象類之間,抽象類和派生類)之間或者互相通信的對象之間常見的組織關系。

　　對象是什麼？

----從概念層面講，對象是某種擁有責任的抽象。

----從規格層面講，對象是一系列可以被其他對象使用的公共接口。

----從語言實作層面來看，對象封裝了代碼和資料

針對接口程式設計，而不是針對實作程式設計

---- 客戶無需知道所使用對象的特定類型，隻需要知道對象擁有客戶所期望的接口。

優先使用對象組合，而不是類繼承

---- 類繼承通常為“白箱複用”，對象組合通常為“黑箱複用”。繼承在某種程度上破壞了封裝性，子類和父類耦合度高；而對象組合則隻要求被組合的對象具有良好定義的接口，耦合度低。

封裝變化點

---- 使用封裝來建立對象之間的分界層，讓設計者可以在分界層的一側進行修改，而不會對另一側産生不良的影響，進而實作層次間的松耦合。

　　類設計的五項原則：

SRP，單一職責原則，一個類應該有且隻有一個改變的理由。

OCP，開放封閉原則，應該能夠不用修改原有類就能擴充一個類的行為。類子產品應該是可擴充的，但是不可修改（對擴充開放，對修改封閉）。

LSP，Liskov替換原則，派生類要與其基類自相容。子類必須能夠替換它們的基類。

DIP，依賴倒置原則，依賴于抽象而不是實作。高層子產品不應該依賴于低層子產品，二者都應該依賴于抽象。抽象不應該依賴于實作細節，實作細節應該依賴于抽象。  

ISP，接口隔離原則，客戶隻要關注它們所需的接口。不應該強迫客戶程式依賴于它們不用的方法。

 設計模式融合了上述設計原則，并提供了對常見設計問題的解決方案核心。

　　抽象，封裝，多态，繼承

　　其中，抽象和封裝是OO的基本。抽象使實際概念得以升華并工程化，進而使設計者能夠使用概念視角來考查和設計複雜系統。封裝用于封裝系統中的各種變化(點)，如内部資料和子類差異等，進而簡化系統程式設計。多态和繼承則僅僅是實作抽象和封裝的必要技術，并非OO本質。

1) 封裝變化：找出應用中可能的變化點，封裝易變代碼，隔離穩定代碼。

2) 多用組合，少用繼承

3) 針對接口程式設計，不針對實作程式設計

4) 為互動對象之間的松耦合設計而努力

5) 類應該對擴充開放，對修改關閉

6) 依賴抽象，不依賴具體類. 如工廠方法（Factory Method）

7) 隻和朋友交談（墨忒耳法則）：在對象的方法内，隻應該調用屬于以下範圍的方法：a) 該對象本身； b) 被當作方法的參數傳遞進來的對象； c) 此方法所建立或執行個體化的任何對象； d) 對象的任何元件（執行個體變量）。

8) 别找我，我會找你（依賴倒置原則）。父類對外提供公共接口，這些接口調用子類（底層）具體實作接口。這條原則需要通過抽象方法（鈎子方法）實作，如模闆方法，架構類。

9) 類應該隻有一個改變的理由

---------------------------------------------------

歡迎轉載，請注明作者和出處

本文轉自 zhenjing 部落格園部落格，原文連結：  http://www.cnblogs.com/zhenjing/archive/2010/12/06/pritciple_design_pattern.html ，如需轉載請自行聯系原作者