最近又在首頁看到幾篇設計模式相關的學習隨筆。回想起來，這幾年在園子里發布的有關設計模式的隨筆都有一個共同的特點。那就是Factory和Singleton居多，如果是系列的，也往往是從這兩個模式開始的。由于能夠堅持把《設計模式》中所有模式都寫完的非常少，所以基本上也很少見到有關其它模式的隨筆。

　　這種情況也很好理解，因為《設計模式》這本書就是按照這個順序來的。最先講述的就是Abstract Factory模式，于是它排第一也無可厚非；排第二的Builder基本不太容易見到；第三的Factory Method由于也叫“Factory”所以往往和Abstract Factory放在一起，或者干脆就混淆了； 第四的Prototype也不是太容易見到；第五位的Singleton簡單易懂，易學易用。而再往后的模式，恐怕作者們就沒什么耐心學下去了……這可能就是為什么Factory和Singleton出現頻率如此之多的原因吧。

　　《設計模式》已經出版超過15年了，到今天已經不是什么新鮮的東西了，可以說正在由“絕招”慢慢向著“基本功”轉變著。然而，這種學習模式的方式方法卻實在令人擔憂。

　　Abstract Factory在實際中并不常見，因為它需要你有兩套并行的繼承體系，需要對同一個抽象有多于一種的實現方式。這種復雜的系統可以說不是每個領域，每個開發人員都能遇到的。在某些特定的領域可能很常見，但是在大多數領域并不需要這么復雜的對象創建方法。這就造成了很多人“殺雞用宰牛刀”，用復雜的方式，解決不那么復雜的問題。后果是增加了不必要的復雜度，給系統維護增加了困難。

　　另一個模式Singleton，由于實現簡單，意圖“似乎”也很明顯。被很多人用來作為“優化”的一種方式。通過這種方式來節省內存空間，減少對象實例。但是單一實例本身就等同于全局變量，而全局變量在幾十年前就已經被證明是“反模式”了，用另一種形態的全局變量來代替另一種形態的全局變量有什么好處么？問題在與，Singleton的“意圖”并不在于優化，而是在于“妥協”。Singleton的目的在于保證對象有單一的實例，這是因為對象必須要有單一的實例，如果存在多個實例，可能會引發錯誤。也就是說，Singleton以犧牲程序的清晰和可維護性，來達到保證程序正確的目的。這跟本就和優化八竿子打不著，這完全是一種設計上的妥協，犧牲一些好處來獲取更大的好處。如果僅僅是為了節省幾個對象實例，而非程序的正確才使用Singleton，那就是丟了西瓜揀芝麻。況且節省那幾個實例也跟本就不可能對程序的性能有太大的影響（特殊領域除外）。

　　人的時間是有限的，23個模式也不是都那么常用，哪些模式才是最經常用到的，才是最值得學習的呢？

　　第一梯隊：Iterator，Observer，Template Method，Strategy

　　Iterator：LINQ，foreach這不都是Iterator么。

　　Observer：MVC的核心，.NET中事件就是Observer。

　　Strategy：對同一個行為有不同實現的時候，如果考慮將行為的實現委托（不是.NET中的委托）給另一個類，那就用到了Strategy。通過這種方式，可以簡單的替換算法的實現類，來達到更換算法的目的。

class Foo
{
  private IBar bar;
  public Foo(IBar bar)
  {
    this.bar = bar;
  }

  public void DoSomething()
  {
    //some code
    bar.DoWhatYouWant();
    //some code
  }
}

class A : IBar
{
  public void DoWhatYouWant()
  {
    //do in A's way
  }
}
class B : IBar
{
  public void DoWhatYouWant()
  {
    //do in B's way
  }
}        

        

        
        
      
        
it知識庫：哪些設計模式最值得學習，轉載需保留來源！
        
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。