最近又在首頁看到幾篇設計模式相關的學習隨筆。回想起來，這幾年在園子里發布的有關設計模式的隨筆都有一個共同的特點。那就是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
??}
}

Template Method：一個算法的同一個步驟有不同的實現，通過繼承來實現。這種方式通過創建子類來改變算法的實現和行為。ASP.NET WebForm中Page的OnInit，OnLoad等事件，就是Template Method

代碼 class?Foo
{
??public?void?DoSomething()
??{
????//some?code
????DoWhatYouWant();
????//some?code
??}
??protected?abstract?void?DoWhatYouWant();
}

class?A:?Foo
{
??protected?override?void?DoWhatYouWant();
??{
????//do?in?A's?way
??}
}

class?B:?Foo
{
??protected?override?void?DoWhatYouWant();
??{
????//do?in?B's?way
??}
}

面向對象的一個重要特點就是多態，也就是對于同一個動作有不同的行為。Strategry通過委托的方式，將一個算法的不同實現委托給其它類；Template Method通過繼承的方式，讓子類實現算法的可變部分，基類則處理算法的流程和不變部分。近年來組合優于繼承的觀點已經成為主流，因此Strategy的處境頻率相對高一些，但是Template Method在解決簡單問題的時候更好用，只要注意繼承層次不要太多（<=3）就好。

?

第二梯隊：Adapter，Facade，Decorator

Adapter：當你需要使用第三方庫，但是又不想太依賴于它的API，以便于今后在需要時可以方便的切換到另一個庫的時候，你就需要在你的代碼和第三方API之間放置一個抽象層，也就需要用Adapter模式了。比如你想使用log4net，如果直接在代碼中到處引用log4net的API，將來有一天需要切換到另一個庫比如EntLib，你的改動量可就大了去了。如果在一開始就自己設計一個API，在代碼中使用自己的API，再用Adapter模式將log4net的API包裝到自己的API中，如果有一天想要切換到Entlib，只要為EntLib在寫一個Adapter就行了。對于IoC框架也是一樣的。不過需要注意的是，如果第三方庫的API接口非常龐大，使用Adapter就會很麻煩，因為你需要包裝太多的東西，那么使用Adapter可能就不是一個太好的主意。或許謹慎考慮確定一個不太可能會變化的第三方庫更好一些。

Facade：基本上用于簡化API，隱藏細節，在一個系統中，高層模塊調用低層模塊時，如果低層模塊API比較復雜，而高層模塊并不需要這種復雜度，那么加一個Facade，可以簡化高層模塊使用API的難度。

Decorator：為一個類的行為增加行為，比如ASP.NET MVC中的Action Filter。

?

第三梯隊：Command，State，Composite

Command：統一接口，Undo/Redo。

State：當你的model有多種狀態，model的行為在每種狀態下并不一樣的時候，就需要用State。如果你有多個相似的Switch，那也可能意味著需要用State來代替Switch。

Composite：ASP.NET WebForm的Page和Control就是一個例子。

?

這些模式和分類只是憑我的感覺，并沒有任何實際的數據做支持，而我的感覺也只來源于我所接觸到的領域和代碼。 希望同學們也可以提供自己接觸到的代碼中，最常見到和用到的模式。

總結

以上是生活随笔為你收集整理的哪些设计模式最值得学习的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。