設計模式學習筆記（一）——物件導向設計模式與原則

 今天聽了《C#物件導向設計模式縱橫談(1)：物件導向設計模式與原則》課程。總結了一些筆記。
 首先介紹了什麼是設計模式：設計模式描述了軟體設計過程中某一類常見問題的一般性的解決方案。
 下面主要討論物件導向設計模式。
 物件導向設計模式描述了類與相互連信的對象之間的組織關係。目的是應對變化、提高複用、減少改變。
 那到底什麼是對象：
  1、從概念層面講，對象是某種擁有職責的抽象；
  2、從規格層面講，對象是一系列可以被其他對象使用的公用介面；
  3、從語言實現層面來看，對象封裝了代碼和資料（也就是行為和狀態）。
 對於這三點，我理解最深的應該是第三點。這可能和我把大多精力放在了代碼實現上有關，然而忽略了編程的的思想。如果我們拋開代碼的實現來看對象的概念，那麼它應該就像一個具體的物體，比如說：榔頭，從概念層面講，榔頭有它的職責，也就是它是做什麼用的（用來砸釘子，當然還會有其他用途，如防身），從規格層面講，比如人使用榔頭砸釘子。
 物件導向的設計模式有三大原則：
  1、這對介面編程，而不是針對實現編程。在知道設計模式之前，我對介面的出現很不理解。不明白為什麼這個什麼都不能實現的東西會存在，當然，也對多態表示茫然。實際上我是還沒有理解物件導向編程的思想。在對設計模式略有瞭解後發現介面的確是一個好東西，用它實現多態的確減少了代碼的修改。
 比如說在《Head First Design Patterns》中有一個例子，說一個有關鴨子的遊戲。遊戲當中有很多種的鴨子，如：野鴨，木頭鴨，鴨子模型。我們首先會想到做一個抽象類別：abstract class Duck，Duck當中有很多的抽象屬性和方法，如quack。我們用子類繼承的時候都會執行個體化這個方法。
 public abstract class Duck
 {
  public abstract void quack()
 }
 
 public class MallardDuck:Duck
 {
  public override void quack()
  {
   Console.Write("I can quack");
  }
 }
當程式成型後，我們有了很多種鴨子，突然，我們發現有的鴨子會飛，我們會在Duck中在加上一個抽象方法abstract void fly();於是我們不得不在所有的子類當中添加fly的實現，有人會說，如果我們在Duck中直接添加fly的實現，不久不用在子類中添加實現了嗎？那老闆就該問你：你見過木頭鴨子滿天飛（哦，天啊！木頭鴨子也飛起來了，這是什麼世界！）。對不起老闆，現在咱們都見到了。
 這時我們換一種想法，如果我們把這些方法都提取出來,把它變成Duck的成員，好像問題就會簡單些。
 哈哈，好像扯的有點遠了，現在回來接著記我的筆記。
  2、優先使用對象組合，而不是類的繼承。
 這就使說多使用“has a”，少使用“is a”，哈哈，我又想說回剛才的例子。換個角度考慮Duck及其功能，我們設計一個fly的介面和一些具體的飛行方法。
 public interface FlyBehavior
 {
  void fly();
 }

 public class FlyWithWing:FlyBehavior
 {
  public void fly()
  {
   Console.Write("I can fly\n");
  }
 }

 public class FlyNoWay:FlyBehavior
 {
  public void fly()
  {
   Console.Write("I can't fly\n");
  }
 } 
 好了，對於Duck來說，現在它應該有一個（has a）fly的方法
 public abstract class Duck
 {
  public Duck()
  {}
  public FlyBehavior flybehavior; 
 }
 現在我們再來實現兩種鴨子
 public class ModelDuck:Duck
 {
  public ModelDuck()
  {
   flybehavior = new FlyNoWay();
  }
 }
 
 public class MallardDuck:Duck
 {
  public MallardDuck()
  {
   flybehavior = new FlyWithWing();
  }
 }
 這樣如果要是在加上某種行為的話，我們就不必在每一種鴨子上下功夫。把注意力放在我們關心的鴨子品種上（別太使勁關注，小心禽流感，“阿切！”）。
  3、封裝變化點，實現松耦合，這點不用多說了。
 課程中提到，編碼當中的設計模式使用不是我們在編程之初就定下來的，應該是重構得到設計模式（Refactoring to Patterns）。哦，原來是這樣，也好理解。在編碼中遇到問題，然後想想應對方式。哈哈，我原來認為開始編程時就指定我們用什麼設計模式呢。
 下面說說設計原則：
  1、單一職責原則（SRP）：一個類應僅有一個引起它變化的原因。
  2、開放封閉原則（OCP）：類別模組應可擴充，不可修改。這裡要說明一下，擴充和修改是不同的。比如：我們要在加一種ModelDuck，那麼我們寫一個ModelDuck的類繼承Duck，這叫擴充，不是修改。什麼是修改，就好像我們開始說的那種作法，為了加一個fly的功能，我們要把所有的子類中加入不同的實現，這叫修改。
  3、Liskov替換原則：子類可替換基類。
  4、依賴倒置原則：高層模組不依賴於低層模組，二者都依賴於抽象。還是剛才的例子：Duck是一個高層模組，fly是低層模組。Duck不依賴於fly，高層模組的改變慢，而低層模組的改變慢。
     抽象不應依賴於實現細節，實現細節應依賴於抽象。fly是一個抽象，它不依賴如何飛行。
  5、介面隔離原則：不強迫客戶程式依賴於它們不用的方法（有道理，木頭鴨子不會飛為什麼要讓它實現飛的功能。）
  最後有人提問介面和抽象類別的區別：
   介面可以多繼承，抽象類別只能但繼承。介面定義組件間的合約。使用抽象類別為一個is a的關係。