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

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

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

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

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

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

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

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

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

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

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