今天聽了《C#面向?qū)ο笤O(shè)計模式縱橫談(1)：面向?qū)ο笤O(shè)計模式與原則》課程?？偨Y(jié)了一些筆記。
 首先介紹了什么是設(shè)計模式：設(shè)計模式描述了軟件設(shè)計過程中某一類常見問題的一般性的解決方案。
 下面主要討論面向?qū)ο笤O(shè)計模式。
 面向?qū)ο笤O(shè)計模式描述了類與相互通信的對象之間的組織關(guān)系。目的是應(yīng)對變化、提高復(fù)用、減少改變。
 那到底什么是對象：
  1、從概念層面講，對象是某種擁有職責(zé)的抽象；
  2、從規(guī)格層面講，對象是一系列可以被其他對象使用的公共接口；
  3、從語言實(shí)現(xiàn)層面來看，對象封裝了代碼和數(shù)據(jù)（也就是行為和狀態(tài)）。
  對于這三點(diǎn)，我理解最深的應(yīng)該是第三點(diǎn)。這可能和我把大多精力放在了代碼實(shí)現(xiàn)上有關(guān)，然而忽略了編程的的思想。如果我們拋開代碼的實(shí)現(xiàn)來看對象的概念，那 么它應(yīng)該就像一個具體的物體，比如說：榔頭，從概念層面講，榔頭有它的職責(zé)，也就是它是做什么用的（用來砸釘子，當(dāng)然還會有其他用途，如防身），從規(guī)格層 面講，比如人使用榔頭砸釘子。
 面向?qū)ο蟮脑O(shè)計模式有三大原則：
  1、這對接口編程，而不是針對實(shí)現(xiàn)編程。在知道設(shè)計模式之前，我對接 口的出現(xiàn)很不理解。不明白為什么這個什么都不能實(shí)現(xiàn)的東西會存在，當(dāng)然，也對多態(tài)表示茫然。實(shí)際上我是還沒有理解面向?qū)ο缶幊痰乃枷?。在對設(shè)計模式略有了 解后發(fā)現(xiàn)接口的確是一個好東西，用它實(shí)現(xiàn)多態(tài)的確減少了代碼的修改。
 比如說在《Head First Design Patterns》中有一個例子，說一個有關(guān)鴨子的游戲。游戲當(dāng)中有很多種的鴨子，如：野鴨，木頭鴨，鴨子模型。我們首先會想到做一個抽象類： abstract class Duck，Duck當(dāng)中有很多的抽象屬性和方法，如quack。我們用子類繼承的時候都會實(shí)例化這個方法。
 public abstract class Duck
 {
  public abstract void quack()
 }
 
 public class MallardDuck:Duck
 {
  public override void quack()
  {
   Console.Write("I can quack");
  }
 }
當(dāng) 程序成型后，我們有了很多種鴨子，突然，我們發(fā)現(xiàn)有的鴨子會飛，我們會在Duck中在加上一個抽象方法abstract void fly();于是我們不得不在所有的子類當(dāng)中添加fly的實(shí)現(xiàn)，有人會說，如果我們在Duck中直接添加fly的實(shí)現(xiàn)，不久不用在子類中添加實(shí)現(xiàn)了嗎？那 老板就該問你：你見過木頭鴨子滿天飛（哦，天??！木頭鴨子也飛起來了，這是什么世界！）。對不起老板，現(xiàn)在咱們都見到了。
 這時我們換一種想法，如果我們把這些方法都提取出來,把它變成Duck的成員，好像問題就會簡單些。
 哈哈，好像扯的有點(diǎn)遠(yuǎn)了，現(xiàn)在回來接著記我的筆記。
  2、優(yōu)先使用對象組合，而不是類的繼承。
 這就使說多使用“has a”，少使用“is a”，哈哈，我又想說回剛才的例子。換個角度考慮Duck及其功能，我們設(shè)計一個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來說，現(xiàn)在它應(yīng)該有一個（has a）fly的方法
 public abstract class Duck
 {
  public Duck()
  {}
  public FlyBehavior flybehavior; 
 }
 現(xiàn)在我們再來實(shí)現(xiàn)兩種鴨子
 public class ModelDuck:Duck
 {
  public ModelDuck()
  {
   flybehavior = new FlyNoWay();
  }
 }
 
 public class MallardDuck:Duck
 {
  public MallardDuck()
  {
   flybehavior = new FlyWithWing();
  }
 }
 這樣如果要是在加上某種行為的話，我們就不必在每一種鴨子上下功夫。把注意力放在我們關(guān)心的鴨子品種上（別太使勁關(guān)注，小心禽流感，“阿切！”）。
  3、封裝變化點(diǎn)，實(shí)現(xiàn)松耦合，這點(diǎn)不用多說了。
 課程中提到，編碼當(dāng)中的設(shè)計模式使用不是我們在編程之初就定下來的，應(yīng)該是重構(gòu)得到設(shè)計模式（Refactoring to Patterns）。哦，原來是這樣，也好理解。在編碼中遇到問題，然后想想應(yīng)對方式。哈哈，我原來認(rèn)為開始編程時就指定我們用什么設(shè)計模式呢。
 下面說說設(shè)計原則：
  1、單一職責(zé)原則（SRP）：一個類應(yīng)僅有一個引起它變化的原因。
  2、 開放封閉原則（OCP）：類模塊應(yīng)可擴(kuò)展，不可修改。這里要說明一下，擴(kuò)展和修改是不同的。比如：我們要在加一種ModelDuck，那么我們寫一個 ModelDuck的類繼承Duck，這叫擴(kuò)展，不是修改。什么是修改，就好像我們開始說的那種作法，為了加一個fly的功能，我們要把所有的子類中加入 不同的實(shí)現(xiàn)，這叫修改。
  3、Liskov替換原則：子類可替換基類。
  4、依賴倒置原則：高層模塊不依賴于低層模塊，二者都依賴于抽象。還是剛才的例子：Duck是一個高層模塊，fly是低層模塊。Duck不依賴于fly，高層模塊的改變慢，而低層模塊的改變慢。
     抽象不應(yīng)依賴于實(shí)現(xiàn)細(xì)節(jié)，實(shí)現(xiàn)細(xì)節(jié)應(yīng)依賴于抽象。fly是一個抽象，它不依賴如何飛行。
  5、接口隔離原則：不強(qiáng)迫客戶程序依賴于它們不用的方法（有道理，木頭鴨子不會飛為什么要讓它實(shí)現(xiàn)飛的功能。）
  最后有人提問接口和抽象類的區(qū)別：
   接口可以多繼承，抽象類只能但繼承。接口定義組件間的合同。使用抽象類為一個is a的關(guān)系。