最近一直在看《Design Patterns: Elements of Reusable Object-Oriented Software》這本書，不知道看過這本書的人是不是有摸不到頭緒，無處下手的感覺， OK，和我一樣/hand. 書裡面講述的23種模式經常把我弄的一蹋糊塗，這本書不看個三、四遍以上是很難理解的， 而且即便看了幾遍， 也是很難把握住精髓。

    裡面講解的例子是用C++和SMALLTALK這兩種OO語言。對於我這種對C++半生不熟的笨鳥來說， 難度是不是太高了些.而且例子的講解並不能使讀者融會貫通。

    呵呵， 我看書的原則就是看不懂的話就過段時間再看，沒聽說過“大俠請重新來過”麼。（而且我看書， 從來不對一本書感冒， 經常是講同一類知識的書穿插著看。對於設計模式---中文版的好象只有這麼一本，E文的倒有一些。）由於已經看了幾遍， 對Design Pattern 結構,內容整體上都有了一定的瞭解，所以剩下的就該用實際的例子來幫我理解掌握Design Patterns。如果這時再返回頭重新看書， 會有種山重水複疑無路， 柳岸花明又一村的感覺。(連點掌聲都沒有)

    其實在JAVA中，到處可見Design Patterns，JDK是設計模式的典型應用。常用的AWT， 裡面包含了AbstractFactory，Composite，Bridge， Strategy，Command，SINGLETON等等模式 我就不細說的啦， 有興趣的朋友可以自己研究， 希望能把心得發給我一份， [email protected], 我會感激的哭的…… ^_- , 迷時師度， 悟時自度。 共同學習進步麼。 這裡介紹幾本關於設計模式的JAVA書先。《THE DESIGN PATTERNS JAVA COMPANION》《Thinking in Patterns with Java》 有興趣的可以去找來看看。E文的. ( FALSE：不要急， 沒看見我在醞釀情緒麼， 君不見黃河之水天上來，奔流到海不 復回麼，菩提本無樹， 鏡臺亦非明）

    例項剖析

    JAVA是個龐大的體系，APPLET，APPLICATION ，JSP/SERVET，EJB，RMI，CORBA，嵌入式JAVA.......應用的範圍很廣。現在學習JAVA的，很多人都是從JSP入手的。不象97,98年那時是從applet，application開始。目前相當多的人單純的為了學JSP而學JSP，java的基礎很薄， 可惜可嘆。為了使大家對設計模式有所瞭解，體會DESIGN PATTERNS 在jsp/servlet的應用,進而擴充套件到java。這裡採用JIVE做為例子。JIVE是基於JSP/SERVLET技術的FORUM，是個open source的software 產品。 到這裡可以下載http://www.coolservlets.com/jive。 它的優秀性就不用我多說了。使用JSP/SERVLET做開發的人都知道。很多人都是靠研究它入門的。 NOTE： 本文不是講解JSP/SERVLET語法、具體實現和程式設計技巧。如果你需要這些，恐怕我會讓你失望的， 還是請到google去search吧。這裡主要是通過JIVE來解析THINKING IN DESIGN PATTERNS FOR JAVA . 包括物件的建立，物件和物件間的結構組合以及物件行為等。由於涉及很多OOP的概念，例如類，物件，繼承，介面，抽象,封裝等等這些亂七八糟的東東。如果對OOP和JAVA不太瞭解，建議請看《THINKING IN JAVA》這本書。

    也有可能我寫的內容裡面會涉及到UML的內容， 這下各位可有福了，由於本人的水平實在不怎麼樣，這些模式我能說多少就是多少了， 現在整個社會都在編故事，講故事。。。。。。如果看我的寫的實在不像話， 那你就當看個故事了：）也有可能說說就跑題了。

     分類

    根據模式的目的將23種模式分為三類：建立型（Creational），結構型（Structural）和行為型（Behavioral）模式。

    建立型（Creational）：建立型模式是用來建立物件的。我們在coding時經常要對類進行例項化, 建立型模式就是提供提供各種不同的solution，從例項化的程式碼中去除硬編碼（hard-coding）， 從而使編碼更加靈活和general, 適用於更復雜的行為。 ·Factory Method ·Abstract Factory Method ·Builder Pattern ·Prototype Pattern ·Singleton Pattern 結構型（Structural）

     結構型模式處理類或物件的組合來獲得更大的結構。 · Adapter pattern · Composite pattern, · Proxy pattern, · Flyweight pattern, · Façade pattern, · Bridge pattern, · Decorator pattern, 行為型（Behavioral）

     行為型模式處理類或物件如何互動 · Observer pattern · Mediator · Memento · Chain of Responsibility · Template pattern · Interpreter in a program. · Strategy pattern · Visitor pattern · State pattern · Command pattern · Iterator pattern

    下面將對JIVE的核心來說說DESIGN PATTERNS

    分析JIVE不是件容易的事情， 裡面涉及OOP的東東很多，所以最好能使用工具。 欲善其事， 必先利其器。呵呵， 我用RATIONAL ROSE， 因為rose實現了UML，能很好 的把設計思路和各種類，介面，物件及之間的關係體現出來。我想通過類圖和code結合來 看，這樣會比只看code效果來的好。 （你也可以使用JBUILDER或j++, 不在於使用什麼， 關鍵看哪個的專案管理方便。我用建模工具rose） 這裡使用RATIONAL ROSE的一個功能----JAVA逆向轉出工程 （我覺的通過這個功能和生成JAVA程式碼這個功能對我提高很大， 不管是掌握JAVA還是掌握UML&ROSE） FIRST，需要將JDK匯入到rose裡. 然後選擇選單TOOLS=>JAVA=>REVERSE ENGINEER JAVA 開啟REVERSE ENGINEER JAVA視窗，選擇JIVE裡我們需要的servlet原始碼 逆向生成模型。當然你需要把classpath設定正確。 Jive裡使用了很多的interface和abstract class, 這是面向物件裡通常使用的。

    為了code的複用和靈活性， DESIGN PATTERNS 的一個非常重要的原則：針對介面程式設計，而不是針對實現程式設計。第二個原則就是： 優先使用物件組合，而不是類繼承。 2.2.1 com.coolservlets.forum package 這個package裡包括很多class和interface。主要封裝forum的基本操作。 （什麼是class和interface？ 呼呼。。。。。。趁我沒還吐血你趕緊去查資料吧。） 不管是使用CGI、ASP還是PHP甚至JSP/SERVLET，我相信很多人或大或小，或簡單或複雜， 都做過BBS。

    那麼建議同志們看看JIVE是如何設計和實現的。每個人看問題的角度是不一樣 的，不管您從哪個角度來看， 我相信你都會從中獲得營養。

============================================================================================

【IT168技術文件】

通常，概念和這些概念在現實世界中的應用是有區別的，設計模式也不例外。 

    設計模式無處不在。在閱讀技術方面的出版物或者瀏覽技術方面的網站時，很容易發現對設計模式的引用。到目前為止，您很可能已經閱讀過（至少翻閱過）一些設計模式方面的書籍，如《Core J2EE Design Patterns》或者Gang of Four編寫的《Design Patterns》。此時，您可能會對設計模式有一些疑問。設計模式如何幫助我？他們是銀彈嗎？使用設計模式有什麼問題嗎？為什麼我不能從整合開發環境（integrated development environment，IDE）中獲得設計模式？

    上述的幾個問題是採用設計模式進行處理過程中遇到的一些經典問題。通常，概念和這些概念在顯示世界中的應用是有區別的，設計模式也不例外。本文將討論設計模式在現實世界中的應用。這些資訊可以幫助您成功地在專案中採用設計模式來作出正確的決定。 

    快速概述

    設計模式提供了一種共享經驗的方式，可以使團體受益和避免不斷的重複發明。設計模式通常捕捉問題的描述、問題的語境、推薦的問題解決方案以及使用解決方案後可以預見到的結果。為了具有最廣泛的適用性（從而對更多的讀者有用），設計模式通常從取決於環境的精確細節中抽象而來。這種抽象性產生了一些把設計模式應用到現有的案例中所必需的譯碼。這是一個重要細節：儘管設計模式是共享專業知識的好方法，但通常它對正確應用專業知識是非常重要的。

    設計模式這個概念最初產生於建築行業。設計師（設計建築物而不是計算機系統）意識到他們需要共享有關正確設計技術的想法。這些想法是在可以使設計師團體從分享經驗和教訓中獲益的設計模式中形成的。設計模式在80年代後期從建築業進入計算機系統領域。面向物件（Object-oriented，OO）原則逐漸得到普及，而設計模式成為培育新的OO追隨者的最佳實踐。

    Richard Gamma等（人們通常把他們稱作 Gang of Four [GoF] ）編著的《Design Patterns: Elements of Reusable Object-Oriented Software》一書使設計模式成為萬眾矚目的焦點。隨著設計模式逐漸普及，他們所涉及的領域就像“Ben and Jerry”效應那樣也逐漸廣泛起來。對那些不熟悉著名冰淇淋品牌的人來說，Ben and Jerry是一家冰淇淋產品的供應商，其冰淇淋產品擁有各種可以想象得到的配料組合（還包括一些您永遠想象不到的）。因此，它就是設計模式，和普通的OO設計模式一樣來源於GoF的著作，但是現在包括了專為開發語言、應用伺服器、行業合成等提供的設計模式。 

    設計模式分類

    設計模式通常根據一些公共特性而組合在一起。GoF的著作把設計模式劃分為三類：Creational、Behavioral和Structural。用於J2EE的設計模式通常劃分為表現層（Presentation Tier）、業務邏輯層（Business Logic Tier）和整合層（Integration Tier）。這種分組方式可以使描述所有設計模式共享的公共細節更加輕鬆，或者使設計模式的分類和發現更加輕鬆。

    在對設計模式實際應用的討論中，需要把設計模式劃分為兩類：broad exposure和isolated use。這種劃分基於設計模式對應用程式設計人員和開發人員的可見性和應用程式的多個部分對設計模式的相依性。 

    Broad exposure 設計模式因為可以影響多個團隊成員或者應用程式的多個方面的設計和開發而聞名。這類設計模式的品質包括： 

    1.採用它會對很多根據設計模式建立的類產生負面影響。 
    2.應用程式的不同部分知道設計模式的使用。 
    3.使用這種設計模式的決定不能輕易取消。

    這類設計模式的例子有Model-View-Controller（MVC）模式、Value Object J2EE模式和Data Access Object（DAO）J2EE模式

    Isolated use是指設計模式的使用是隱藏細節的設計模式。這類設計模式的品質包括： 

    1.設計模式不影響其他團隊成員或者應用程式其他部分的工作。 
    2.可以輕鬆地更改使用設計模式的決定，而且產生的影響極小。

    這類設計模式的例子有Singleton GoF模式或者Intercepting Filter J2EE模式。

    將設計模式劃分為幾類為了解設計模式的範圍提供了一種快速的方法。瞭解範圍使評估設計模式的影響更加輕鬆。可以使用或者拋棄這種設計模式嗎？一旦採用這種設計模式就會影響應用程式的設計嗎？這種設計模式影響了應用程式的多個部分和其他的應用程式了嗎？預先了解這些影響為採用設計模式提供了指導。

======================================================================================

 設計模式應用AntiPatterns 

    隨著設計模式逐漸普及，出現了另一種叫做AntiPatterns的模式型別。儘管設計模式提供了關於可重複的最佳方法的專業知識，但是AntiPatterns通常描述應當避免的重複行為。AntiPatterns 驗證了這樣的事實：做錯事情和辦對事情的人一樣多。 

    本節將探討設計模式採用中的AntiPatterns。瞭解這些AntiPatterns可以幫助您避免設計模式採用中的缺陷。如同設計模式一樣，在他們提供了一些遠見或者他們是一些非常熟悉的環境時，在他們可以為您的經驗新增色彩和使您不再感到孤獨時，此處的AntiPatterns是一個全新的概念。如果您想閱讀更多有關AntiPatterns的資料，請參見本文結尾處的資源列表。 

    AntiPattern清單

設計模式?是的，我們全部擁有

    問題：決定在專案中使用哪一種設計模式。 
    應用： 既有broad exposure又有isolated use設計模式。 
    環境：一位開發人員通過介紹希望在一項工程中使用設計模式。 
    動力：AntiPattern的動力通常有兩種來源。一種是開發人員通過包括設計模式的最佳實踐來改進專案的渴望。另一種是開發人員天生的好奇心驅使他利用這個專案來研究設計模式。 
    推薦的解決方案：專案中應用了所有知名的設計模式。設計模式手冊生成一份清單，而目標是可以核對所有的設計模式。 
    產生的語境：專案團隊和交付的應用程式由於不自然地引入太多設計模式而遭受損失。這就導致設計和開發非常複雜。這種不必要的複雜性會從已經完成的工作量、開發團隊瞭解發生事情的能力、應用程式的實際效能和功能的正確性等方面影響開發成果。 
    設計基本原理：設計模式是專業知識的主要來源。儘管使用他們的效果很好，但是全部使用他們就未必也是好的。 
實際解決方案：設計模式的描述包含了使用模式的目標語境。必須考慮如何確保設計模式匹配專案。第二，設計模式不是來源於當某人閱讀了一本設計模式的著作後，問：“我可以把這個設計模式使用在什麼地方？”而是來源於某人尋找已發現問題的解決方案。 

    Developer/Project AntiPattern的實現(也稱為：Design pattern xyz? Yeah，我們有10個)

    問題：在專案中或者專案之間控制設計模式的實現。 
    應用：broad exposure和isolated use設計模式都從解決這種環境中受益。但是，broad exposure設計模式無疑控制了實現。 
    語境：開發團隊將設計模式結合到專案中。團隊由許多經驗豐富的開發人員組成，他們知道應該什麼時候使用設計模式。所以會正確的設計模式。如果涉及到多個專案，專案之間沒有設計模式實現共享。 
    動力：最終期限日益臨近，團隊成員工作效率很高。重新使用實現會影響團隊效率。假設他們都是專家，他們的實現都非常優秀。在多專案情況中，跨團隊通訊和程式碼共享要麼沒有被考慮，要麼被作為進度表中的潛在影響被排除。 
    推薦的解決方案：團隊可以根據需要單獨包含和實現設計模式。 
    產生的語境：即使使用了正確的設計模式，但是他們是以很多不同的方式實現的。在限制整合和重新使用成果的實現之間存在不相容。很多不必要的時間和工作被花費在維護、除錯和擴充套件各種實現上。最終，各種實現都將被統一。 
    設計基本原理：應當允許專家成員獨立工作。只要所包含的設計模式足夠好，就不需要共享實現。 
    實際解決方案：開發團隊應當協調設計模式的使用。共享設計模式的公共實現可在將來降低成本，但是更重要的是，它使開發人員之間互相相容。如果需要，這種共享可以被限制到劃歸先前討論的broad exposure設計模式內。重用實現在專案間也極有價值，尤其在未來將要整合的時候。 

    設計模式採用中IDE的角色

    IDE在繼續發展和提供更多的功能。最初的IDE組成了一種編輯環境和一些除錯工具。現在，他們通常包含設計環境、審計工具、配置管理系統整合等等。隨著IDE不斷擴充套件範圍，需要確認他們在設計模式實現中的角色。誠然，設計模式在開發語言中實現，而IDE可以用於編輯原始碼。但是，IDE可以扮演其他的角色嗎?

    一些IDE具有下拉選單，使您能夠選擇應用程式中包括的設計模式。雖然這可以加快設計模式的使用，但是它只會導致更快地編寫出極差的程式碼。評估這個特性需要記住幾個因素。

    第一，設計模式在抽象中描述問題，並需要一些譯碼來達到正確的實現。但是，他們常常包含“示例實現（sample implementation）”，並且IDE正是將這種示例類結構插入到應用程式中。這很可能不是所需要的實現，並且把他們放到應用程式中將帶來更多的困惑，以及需要更多的編輯和重構工作而不是思考最初的實現。 
    第二，和IDE拖放設計模式方法有關的另一個問題是前面討論的兩種AntiPatterns。加快設計模式的實現很可能會產生大量的設計模式應用，以及同一設計模式的多種版本，而不是解決任意問題的版本。

    設計模式面臨的挑戰不僅僅是得到一次快速實現，而是確定使用了正確的實現，以及機構中已有的一個完美的實現。

=======================================================================================

 BEA WebLogic Workshop 8.1和設計模式

    您可能是一位BEA的客戶，如果您正在閱讀本文，您可能想知道新的BEA WebLogic Workshop 8.1是如何影響您的設計模式考慮的。首先，WebLogic Workshop是IDE，因此前面有關IDE的章節同樣適用。對這些討論感興趣的Workshop的兩個額外方面是控制元件和預實現的設計模式。

    WebLogic Workshop Controls是打包功能的一種方法，可以輕鬆將其包含到使用Workshop IDE的應用程式中。打包包括IDE必需的可視元素、執行時行為、要求的配置等等。控制元件是如何影響設計模式應用的呢？還記得設計模式在前面劃分為isolated use和broad exposure嗎？劃分到isolated use類的設計模式可能被打包成 Workshop Controls。把設計模式作為控制元件打包可使 Workshop IDE的其他使用者共享實現，從而避免了每一個Developer/Project AntiPattern中的實現。

    您可能想知道為什麼broad exposure設計模式為什麼不可以作為控制元件實現。原因是broad exposure設計模式導致建立了許多其他類或者獨立於其他應用程式。這種情況就不適合控制元件的即插即用方面。broad exposure設計模式的採用應當三思而後行，一旦採用就不能輕易取消。這些要求不符合WebLogic Workshop Control的目標。

    WebLogic Workshop還具有很多預實現設計模式，如Pageflow和使用者介面結構。在Workshop 中，您可以建立JSP和定義Pageflow來控制Web應用程式頁面之間的定位。在這種情況下，WebLogic Workshop使用流行的Apache Struts 表現層框架。Workshop的這個方面（使用 Struts）提供了一種Model-View-Controller（MVC）設計模式實現，意味著不用建立自己的MVC實現。Workshop包含的其他功能很可能替代您自己的設計模式實現。儘管一些設計模式實現的開盒即用很好，但是應當驗證不僅實現而且實現建立的WebLogic任何依從性也非常合適。 

    成功採用設計模式的三個步驟

    如何把設計模式的採用和日益臨近的最後期限、緊縮的預算和很多公司現有的有限團隊資源相結合？以下是成功制訂設計模式的三個步驟。 

    強大的通訊和培訓

    許多機構擁有領先技術，可能正式通過了設計師論壇的論證或者非正式的公認專家。這些領先廠商將推廣設計模式採用中的開放通訊，並將培訓開發具體設計模式的團隊。通訊應當跨開發團隊和專案以便預先防止採用豎井和多種惟一的實現（謹記每個Developer/Project AntiPattern的實現）。培訓可以採用正式的internal lunch-and-learns、正式的internal class或者派一些員工參加外部培訓。這些培訓方式將促進正確的設計模式應用程式。如果僅有極少的觀眾能夠參加培訓，最佳的候選人是那些感覺適合在回來後能夠培訓其同事的人。 

    設計模式採用指導

    設計模式可用於使專案受益，但是他們也可能因為誤用而對應用程式造成損害。應當鼓勵採用他們，但是對其的採用應當受到審閱和驗證。設計模式可以包含在設計和開發過程中。在任何一種情況中，設計模式的使用應當由審閱者確認和驗證。在審閱過程中還可能會遇到這樣的情況，額外的設計模式不適用於最初包括的地方。即使環境中沒有進行正式的審閱，這一步驟也可以通過同事審閱或者團隊討論來完成。這一步驟中的審閱者要麼是主要團隊的成員，要麼與他們建立開放通訊。

    指導採用對於broad exposure類別的設計模式非常關鍵。這些設計模式具有很多相關的風險，因為他們將建立依賴性。這些依賴性可能在一些物件類中，例如，只工作在更加廣泛的DAO設計模式實現範圍中的資料訪問物件（DAO）、或者跨應用程式邊界（如使用Value Object設計模式在應用程式和應用程式層之間傳輸資料）。這些設計模式也可以由專案中的其他人或者不同專案的人實現，而且實現應當重新使用，不同於建立另一種獨特的實現。 

    重用實現,不只是設計模式

    只要在建立自己的設計模式實現中有一定的滿足，團隊和公司就可以在重用發生在程式碼層時，而不是設計創意層時獲得更多益處。使企業獲益的最初設計模式是改進的實現。但是，真正的目標是重用實現。重用實現將導致：a)其他可重用的類（取決於公共實現）；b)縮短開發時間和降低成本；c)縮短維護時間和降低成本；d)在應用程式之間和內部輕鬆整合。

    這種重用對broad exposure設計模式非常重要（有時是基本的）。這些設計模式建立了外部依賴性（整合將從公共實現中受益）或者產生全部的自定義類庫（如果有公共基礎將可重用）。isolated use設計模式也可以從重用中獲益，但是如果他們是根據具體情況定製的，他們就非常難以重用。

    有時您可能會問自己：“如果重用比較好，為什麼設計模式和可以重用的實現不可以一同應用呢？”在我們討論設計模式如何使更多讀者獲益的時候才會討論這個問題。如果可能，如果已經預定義了實現，那麼達到廣泛適用性這個目標就會非常困難。然而，一旦設計模式被應用到特殊的問題域或者技術基礎設施中，那麼就可以重用在該環境中產生的實現。 

    架構中的設計模式

    這看起來像是一件可怕的任務，需要掌握設計模式如何應用在實際情況中，如何構建優質的實現，以及如何促進重用實現。完成該任務的方法之一就是在環境中引入應用程式架構。應用程式架構提供了應用程式需要的結構，從而使開發團隊可以關注應用程式的域邏輯。這包含了已實現的設計模式。除了重用設計模式概念或者單個實現之外，可以在多個專案和應用程式之間重用架構。這種共享的公共實現確保了相容性，併為開發和維護多種不同的實現提供了一種低成本替代方案。相容性提供了重新使用需要的技術基礎。沒有足夠的篇幅在這裡深入討論架構的其他重要品質，如執行時監測和管理、可配置應用程式邏輯和適應性行為等。您可以從Carnegie Mellon Software Engineering Institute (www.sei.cmu.edu/ata/ata_init.html) 中學習到更多有關架構的知識。 

    結束語

    設計模式是一種令人驚異的資源，應該使用他以增加您的優勢。雖然設計模式提供了可重用的概念，但是面臨的挑戰是決定使用哪一種設計模式和致力於可以重用的實現。通過了解採用設計模式中會產生的風險，就可以在繼續學習和實現更多設計模式時避免風險。按照本文概述的步驟會產生一個流程，用於在團隊和機構中推廣成功的設計模式採用。