看到一篇很有深度的文章講述GOF和J2ee，分享一下
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的設計模式。雖然它是隱性，但不是可以越過的。