設計模式的五大設計原則

　　這裡我總結了設計模式的五個設計原則，當然，實際可能不止這五種，但是這裡總結的是最常見，也是最常用的五種設計原則。設計原則是我們軟體設計的目标，設計模式是是我們的具體做法。

一，單一職責原則(SRP)：

　　1，SRP(Single Responsibilities Principle)的定義：就一個類而言，應該僅有一個引起它變化的原因。簡而言之，就是功能要單一。

　　2，如果一個類承擔的職責過多，就等于把這些職責耦合在一起，一個職責的變化可能會削弱或者抑制這個類完成其它職責的能力。這種耦合會導緻脆弱的設計，當變化發生時，設計會遭受到意想不到的破壞。(靈活軟體開發)

　　3，軟體設計真正要做的許多内容，就是發現職責并把那些職責互相分離。(靈活軟體開發)

二，開放-封閉原則(OCP)：

　　1，OCP(Open-Close Principle)的定義：就是說軟體實體(類，方法等等)應該可以擴充，但是不能修改。它是軟體設計中也是最重要的一種設計原則。

　　2，OCP的兩個特征：

　　　　1> 對于擴充是開放的。

　　　　2> 對于修改是封閉的。

　　3，什麼時候應用OCP原則呢？

　　　　在我們最初編寫代碼時，假設變化不會發生，當變化發生時，我們就建立抽象(比如抽象類，接口等等)來隔離以後發生的同類變化。

　　4，開放-封閉原則是面向對象設計的核心所在。遵循這個原則可以帶來面向對象技術所聲稱的巨大好處，也就是可維護，可擴充，可複用，靈活性好。開發人員應該僅對程式中呈現出頻繁變化的那些部分做出抽象，然而，對于應用程式中的每個部分都刻意地進行抽象同樣不是一個好主意。拒絕不成熟的抽象和抽象本身一樣重要。

　　5，OCP的UML圖：

　　

三，依賴倒轉原則(DIP)：

　　1，DIP(Dependence Inversion Principle)的定義：抽象不應該依賴細節，細節應該依賴于抽象。簡單說就是，我們要針對接口程式設計，而不要針對實作程式設計。

　　反面例子UML圖：

　　

　　缺點：高層子產品太依賴低層子產品，耦合太緊密。低層子產品發生變化會影響到高層子產品。

　　解決方法：利用依賴倒置原則使高層子產品和低層子產品都依賴于抽象(接口或抽象類)。

　　修改後的UML圖如下：

　　

　　優點：這樣的話修改低層子產品不會影響到高層子產品，減小了它們之間的耦合度，增強系統的穩定性。

　　總結：依賴倒置原則其實可以說是面向對象設計的标志，用哪種語言來編寫程式不重要，如果編寫時考慮的都是如何針對抽象程式設計而不是針對細節程式設計，即程式中所有的依賴關系都是終止于抽象類或者接口，那就是面向對象的設計，反之那就是過程化的設計了。

四，裡氏替換原則(LSP)：

　　1，LSP(Liskov Substitution Principle)的定義：子類型必須能夠替換掉它們的父類型。簡單地說，這是因為子類型繼承了父類，是以子類可以以父類的身份出現。

　　執行個體UML圖：

　　實作的C#代碼：

public class Animal
    {
        public void Eat() { }
        public void Drink() { }
        public void Run() { }
        public void Shout() { }
    }

    public class Cat : Animal
    { }

    public class Dog : Animal
    { }

    public class Cattle : Animal
    { }

    public class Sheep : Animal
    { }      

class Program
    {
        static void Main(string[] args)
        {
            Animal animal = new Cat();//根據需求的變化，這裡可以替換成Dog,Cattle或Sheep，程式其它地方不需要改變
            animal.Eat();
            animal.Drink();
            animal.Run();
            animal.Shout();
        }
    }      

　　總結：也正是因為有了裡氏替換原則，使得繼承複用成為了可能。隻有當子類可以替換掉父類，軟體機關的功能不受到影響時，父類才能真正被複用，而子類也能夠在父類的基礎上增加新的行為。

五，迪米特法則(LoD)：

　　1，LoD(Law of Demeter)的定義：如果兩個類不必彼此直接通信，那麼這兩個類就不應當直接的互相作用。如果其中一個類需要調用另一個類的某一個方法的話，可以通過第三者轉發這個調用。

　　在類的結構設計上，每一個類都應當盡量降低成員的通路權限，也就是說，一個類包裝好自己的private狀态，不需要讓别的類知道的字段或行為(方法)就盡量不要公開。

原文來自：http://www.cnblogs.com/mcgrady/archive/2012/09/23/2697922.html