設計模式的侷限性與適用性

       《設計模式》的出版，是軟體開發領域的一個關鍵轉折點。設計模式理論的出現，讓我們對軟體的關注點，從如何在特定語言中實現最好的演算法，提升為如何在特定環境下找到特定軟體問題的最佳解決辦法。這個轉變不是一夜完成的，因為在這本書誕生前，軟體模式運動已經進行多年。但這本書引領我們超越了在程式碼重用上的爭議，上升到設計重用的高度；這本書第一次明確宣佈了模式時代的到來。

       審讀此書手稿時，我感到非常震撼——它使用的抽象手法是如此輕易，而又清晰地描述了設計模式。對開發者來說，不再需要就演算法、基於特定語言的物件構造、迴圈或條件爭得面紅耳赤，而可以用Visitor或Flyweight這樣簡潔的模式名一下子將原來需要幾頁紙才能說清楚的實現細節、設想、限制和適用性準確定義。團隊成員間的有效溝通，無疑是軟體開發的一個要素，設計模式恰能在這裡起到重要作用，有了它，開發者可以在比以往高得多的抽象層面上實現準確、清晰溝通。

       我當時最感興趣的是Visitor模式。那時候我一直在從事後端編譯器開發工作，讀完手稿後，我馬上根據Visitor模式重構了程式碼。重構後的編譯器變得更為靈活、易於擴充套件和維護，隊友理解也容易多了。而Chain of Responsibility則一直是我的最愛，因為它非常適用於我過去20年一直從事的分散式系統和中介軟體工作。我在不少系統中成功使用了這個模式。和其他很多模式一樣，第一次聽到Chain of Responsibility時，你不會有什麼特別感覺。而我這麼多年已經看到太多脆弱而笨拙的分散式系統了，如果他們的設計者運用這個模式，完全可以避免這些問題。

       當然，設計模式本身有其適用範圍，這是我們不得不考慮的。過去10年，Erlang和Haskell等函數語言程式設計(FP)語言引起了越來越多人的興趣。而一些著名的FP語言程式設計師甚至公開宣稱：《設計模式》講的模式並不適用於FP。我自己已經從OOP轉到FP，因此非常同意這種觀點。《設計模式》的關注點在OOP，確實不太適合FP語言。此外，設計模式本身已在FP中長期存在，絕大多數時候，它們本身就已經是這種語言的一個組成部分了。

       侷限性和適用性，本身就是設計模式的一個部分。懂得這些模式，就意味著我們不僅要知道什麼時候該用，也要知道什麼時候不該用。作為2009年的軟體從業者，我們可以很輕鬆接受這個事實了吧。

【本文轉自《程式設計師》2009年12月刊 特別專題：設計模式15年】 

文/Steve Vinoski 譯/羅小平

作者簡介：Steve Vinoski，《Design Patterns》的審稿人。著名中介軟體技術專家，他被公認為是CORBA領域裡世界領先的專家之一，《IEEE Internet Computing》專欄作家，是《Advanced CORBA Programming with C++》【中譯名：《基於C++ CORBA高階程式設計》】一書的作者之一。

Blog: http://steve.vinoski.net/blog/

【作者：劉偉   http://blog.csdn.net/lovelion】