C#面向對象設計模式縱橫談 學習筆記1 面向對象設計模式與原則

設計模式的第一課內容主要是介紹了什麼是設計模式

Gof23種設計模式：歷史性著作《設計模式：可復用面向對象軟件的基礎》一書中描述了23種經典面向對象設計模式，創立了模式在軟件設計中的地位。該書四位作者被人們並稱為Gang of Four （GoF），"四人組"，該書描述的23種經典設計模式又被人們稱為Gof23 種設計模式。

Gof23種設計模式並不意味著它表示了所有的面向對象的設計模式。面向對象的設計模式也並不意味著代表所有的設計模式。Gof23種設計模式只是設計模式的基礎。

面向對象的設計模式主要解決的是"類與相互通信的對象之間的組織關系，包括它們的角色、職責、協作方式幾個方面。面向對象設計模式的目的是應對變化，提高復用。面向對象的設計模式是與語言無關的。它可以通過各種面向對象的語言來實現如C++、C#、Java等。

我們在編程當中，都了解面向對象的語言的三大特性：封裝、繼承、多態。但是，僅僅通過面向對象的語言是不能夠完全了解面向對象的設計的。面向對象語言的三大特性是為了實現面向對象而存在的，可以說面向對象是一篇文章，而三大特性是文章的寫作技巧，這些寫作技巧是為了寫這篇文章而服務的。

那麼這裡有一個小示例，可以初步的了解面向對象設計。

public abstract class Employee
...{
     public abstract int GetSalary();
}

public class Engineer : Employee
...{
       public override int GetSalary()
...{
        //.....
       }
}

public class Sales : Employee
...{
       public override int GetSalary()

...{
       //....
       }
}

這裡有一個Employee的抽象類，兩個繼承於Employee的派生類。GetSalary是一個抽象方法，這個方法的調用由派生類的類型決定。

我們現在還有一個工廠類

public class EmployeeFactory
...{
        public Employee GetEmployee(string EmployeeID)
...{
            Employee objEmp = null;

            switch (EmployeeID)
...    {
                case "Enginner":
                objEmp = new Engineer();
                break;
                case "Sales":
                objEmp = new Sales();
                break;
           }

           return objEmp;
     }
}

我們可以在程序種直接可以調用這個工廠類，來得到一個Employee

static void Main()
...{
         EmployeeFactory objFactory = new EmployeeFactory();
         Employee objEmp = objFactory.GetEmployee("Sales");
         int Salary = objEmp.GetSalary();
}

如果這時候，我們的Employee類型增加了一個Worker。那麼我們只需要新增一個Worker類，並僅僅需要修改GetEmployee的內部實現，其他的我們可以不作任何修改。Engineer和Sales類也可以不用修改。那麼就達到了一個松耦合的目的。這裡我們GetEmployee的參數可以是別的類型，比如說枚舉，或整形等。

那麼我們從宏觀的層面看就是面向對象的構建方式更能適應軟件的變化，能將變化所帶來的影響減為最小。

從微觀的層面來看面向對象的方式更強調各個類的"責任"，新增員工類型不會影響原來員工類型的實現代碼。實際上就是對原有代碼的擴展。

對象是什麼？

• 從概念層面講，對象是某種擁有責任的抽象。
• 從規格層面講，對象是一系列可以被其他對象使用的公共接口。
• 從語言實現層面來看，對象封裝了代碼和數據。

面向對象的設計原則：

• 針對接口編程，而不是針對實現編程：客戶無需知道所使用對象的特定類型，只需要知道對象擁有客戶所期望
  的接口。
• 優先使用對象組合，而不是類繼承：類繼承通常為"白箱復用"，對象組合通常為"黑箱復用"。繼承在某種程度
  上破壞了封裝性，子類父類耦合度高；而對象組合則只要求被組合的對象具有良好定義的接口，耦合度低。
• 封裝變化點：使用封裝來創建對象之間的分界層，讓設計者可以在分界層的一側進行修改，而不會對另一側產生不良的影響，從而實現層次間的松耦合。
• 使用重構得到模式：設計模式的應用不宜先入為主，一上來就使用設計模式是對設計模式的最大誤用。沒有一步到位的設計模式。提倡Refactoringto Patterns
• 單一職責原則：一個類應該僅有一個引起它變化的原因。
• 開放封閉原則：類模塊應該是可擴展的，但是不可修改（對擴展開放，對更改封閉）
• Liskov 替換原則：子類必須能夠替換它們的基類
• 依賴倒置原則：高層模塊不應該依賴於低層模塊，二者都應該依賴於抽象。 抽象不應該依賴於實現細節，實現細節應該依賴於抽象。
• 接口隔離原則：不應該強迫客戶程序依賴於它們不用的方法。