著名的EJB領域頂尖的專家Richard Monson-Haefel在其個人網站:www.EJBNow.com中極力推薦的GoF的《設計模式》,原文如下:
Design Patterns
Most developers claim to experience an epiphany reading this book. If you've never read the Design Patterns book then you have suffered a very serious gap in your programming education that should be remedied immediately.
翻譯: 很多程序員在讀完這本書,宣佈自己相當於經歷了一次"主顯節"(紀念那穌降生和受洗的雙重節日),如果你從來沒有讀過這本書,你會在你的程序教育生涯裏存在一個嚴重裂溝,所以你應該立即挽救彌補!
可以這麼說：GoF設計模式是程序員真正掌握面向對象核心思想的必修課。雖然你可能已經通過了SUN的很多令人炫目的技術認證，但是如果你沒有學習掌握GoF設計模式，只能說明你還是一個技工。
在瀏覽《Thingking in Java》(第一版)時，你是不是覺得好象這還是一本Java基礎語言書籍？但又不純粹是，因爲這本書的作者將面向對象的思想巧妙的融合在Java的具體技術上，潛移默化的讓你感覺到了一種新的語言和新的思想方式的誕生。
但是讀完這本書，你對書中這些蘊含的思想也許需要一種更明晰更系統更透徹的瞭解和掌握，那麼你就需要研讀GoF的《設計模式》了。
《Thingking in Java》(第一版中文)是這樣描述設計模式的：他在由Gamma, Helm和Johnson Vlissides簡稱Gang of Four(四人幫),縮寫GoF編著的《Design Patterns》一書中被定義成一個“里程碑”。事實上，那本書現在已成爲幾乎所有OOP(面向對象程序設計)程序員都必備的參考書。(在國外是如此)。
GoF的《設計模式》是所有面向對象語言(C++ Java C#)的基礎，只不過不同的語言將之實現得更方便地使用。
GOF的設計模式是一座"橋"
就Java語言體系來說，GOF的設計模式是Java基礎知識和J2EE框架知識之間一座隱性的"橋"。
會Java的人越來越多，但是一直徘徊在語言層次的程序員不在少數，真正掌握Java中接口或抽象類的應用不是很多，大家經常以那些技術只適合大型項目爲由，避開或忽略它們，實際中，Java的接口或抽象類是真正體現Java思想的核心所在，這些你都將在GoF的設計模式裏領略到它們變幻無窮的魔力。
GoF的設計模式表面上好象也是一種具體的"技術"，而且新的設計模式不斷在出現，設計模式自有其自己的發展軌道，而這些好象和J2EE .Net等技術也無關！
實際上，GoF的設計模式並不是一種具體"技術",它講述的是思想，它不僅僅展示了接口或抽象類在實際案例中的靈活應用和智慧，讓你能夠真正掌握接口或抽象類的應用，從而在原來的Java語言基礎上躍進一步，更重要的是，GoF的設計模式反覆向你強調一個宗旨：要讓你的程序儘可能的可重用。
這其實在向一個極限挑戰：軟件需求變幻無窮，計劃沒有變化快，但是我們還是要尋找出不變的東西，並將它和變化的東西分離開來，這需要非常的智慧和經驗。
而GoF的設計模式是在這方面開始探索的一塊里程碑。
J2EE等屬於一種框架軟件，什麼是框架軟件？它不同於我們以前接觸的Java API等，那些屬於Toolkist(工具箱)，它不再被動的被使用，被調用，而是深刻的介入到一個領域中去，J2EE等框架軟件設計的目的是將一個領域中不變的東西先定義好，比如整體結構和一些主要職責(如數據庫操作 事務跟蹤 安全等)，剩餘的就是變化的東西，針對這個領域中具體應用產生的具體不同的變化需求，而這些變化東西就是J2EE程序員所要做的。
由此可見，設計模式和J2EE在思想和動機上是一脈相承，只不過
1.設計模式更抽象，J2EE是具體的產品代碼，我們可以接觸到，而設計模式在對每個應用時纔會產生具體代碼。
2.設計模式是比J2EE等框架軟件更小的體系結構，J2EE中許多具體程序都是應用設計模式來完成的，當你深入到J2EE的內部代碼研究時，這點尤其明顯，因此，如果你不具備設計模式的基礎知識(GoF的設計模式)，你很難快速的理解J2EE。不能理解J2EE,如何能靈活應用？
3.J2EE只是適合企業計算應用的框架軟件，但是GoF的設計模式幾乎可以用於任何應用！因此GoF的設計模式應該是J2EE的重要理論基礎之一。
所以說，GoF的設計模式是Java基礎知識和J2EE框架知識之間一座隱性的"橋"。爲什麼說隱性的？
GOF的設計模式是一座隱性的"橋"
因爲很多人沒有注意到這點，學完Java基礎語言就直接去學J2EE,有的甚至鴨子趕架，直接使用起Weblogic等具體J2EE軟件，一段時間下來，發現不過如此，挺簡單好用，但是你真正理解J2EE了嗎？你在具體案例中的應用是否也是在延伸J2EE的思想？
如果你不能很好的延伸J2EE的思想，那你豈非是大炮轟蚊子，認識到J2EE不是適合所有場合的人至少是明智的，但我們更需要將J2EE用對地方，那麼只有理解J2EE此類框架軟件的精髓，那麼你才能真正靈活應用Java解決你的問題，甚至構架出你自己企業的框架來。(我們不能總是使用別人設定好的框架，爲什麼不能有我們自己的框架？)
因此，首先你必須掌握GoF的設計模式。雖然它是隱性，但不是可以越過的。
關於本站“設計模式”
Java提供了豐富的API，同時又有強大的數據庫系統作底層支持，那麼我們的編程似乎變成了類似積木的簡單"拼湊"和調用，甚至有人提倡"藍領程序員",這些都是對現代編程技術的不瞭解所至.
在真正可複用的面向對象編程中,GoF的《設計模式》爲我們提供了一套可複用的面向對象技術,再配合Refactoring(重構方法),所以很少存在簡單重複的工作,加上Java代碼的精煉性和麪向對象純潔性(設計模式是java的靈魂),編程工作將變成一個讓你時刻體驗創造快感的激動人心的過程.
爲能和大家能共同探討"設計模式",我將自己在學習中的心得寫下來,只是想幫助更多人更容易理解GoF的《設計模式》。由於原著都是以C++爲例, 以Java爲例的設計模式基本又都以圖形應用爲例,而我們更關心Java在中間件等服務器方面的應用,因此,本站所有實例都是非圖形應用,並且順帶剖析Jive論壇系統.同時爲降低理解難度，儘量避免使用UML圖.
如果你有一定的面向對象編程經驗,你會發現其中某些設計模式你已經無意識的使用過了;如果你是一個新手,那麼從開始就培養自己良好的編程習慣(讓你的的程序使用通用的模式,便於他人理解;讓你自己減少重複性的編程工作),這無疑是成爲一個優秀程序員的必備條件.
整個設計模式貫穿一個原理:面對接口編程，而不是面對實現.目標原則是:降低耦合,增強靈活性.