通常，概念和這些概念在現實世界中的應用是有區別的，設計模式也不例外。
設計模式無處不在。在閱讀技術方面的出版物或者瀏覽技術方面的網站時，很容易發現對設計模式的引用。到目前爲止，您很可能已經閱讀過（至少翻閱過）一 些設計模式方面的書籍，如《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 設計模式因爲可以影響多個團隊成員或者應用程序的多個方面的設計和開發而聞名。這類設計模式的品質包括：
設計模式無處不在。在閱讀技術方面的出版物或者瀏覽技術方面的網站時，很容易發現對設計模式的引用。到目前爲止，您很可能已經閱讀過（至少翻閱過）一 些設計模式方面的書籍，如《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 設計模式因爲可以影響多個團隊成員或者應用程序的多個方面的設計和開發而聞名。這類設計模式的品質包括：
- 採用它會對很多根據設計模式創建的類產生負面影響。
- 應用程序的不同部分知道設計模式的使用。
- 使用這種設計模式的決定不能輕易取消。
這類設計模式的例子有Model-View-Controller（MVC）模式、Value Object J2EE模式和Data Access Object（DAO）J2EE模式
Isolated use是指設計模式的使用是隱藏細節的設計模式。這類設計模式的品質包括：
Isolated use是指設計模式的使用是隱藏細節的設計模式。這類設計模式的品質包括：
- 設計模式不影響其他團隊成員或者應用程序其他部分的工作。
- 可以輕鬆地更改使用設計模式的決定，而且產生的影響極小。
這類設計模式的例子有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 ([url]www.sei.cmu.edu/ata/ata_init.html[/url]) 中學習到更多有關架構的知識。
結束語
設計模式是一種令人驚異的資源，應該使用他以增加您的優勢。雖然設計模式提供了可重用的概念，但是面臨的挑戰是決定使用哪一種設計模式和致力於可以重用的實現。通過了解採用設計模式中會產生的風險，就可以在繼續學習和實現更多設計模式時避免風險。
按照本文概述的步驟會產生一個流程，用於在團隊和機構中推廣成功的設計模式採用。
參考資料
將設計模式劃分爲幾類爲了解設計模式的範圍提供了一種快速的方法。瞭解範圍使評估設計模式的影響更加輕鬆。可以使用或者拋棄這種設計模式嗎？一旦採用 這種設計模式就會影響應用程序的設計嗎？這種設計模式影響了應用程序的多個部分和其他的應用程序了嗎？預先了解這些影響爲採用設計模式提供了指導。
設計模式應用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 ([url]www.sei.cmu.edu/ata/ata_init.html[/url]) 中學習到更多有關架構的知識。
結束語
設計模式是一種令人驚異的資源，應該使用他以增加您的優勢。雖然設計模式提供了可重用的概念，但是面臨的挑戰是決定使用哪一種設計模式和致力於可以重用的實現。通過了解採用設計模式中會產生的風險，就可以在繼續學習和實現更多設計模式時避免風險。
按照本文概述的步驟會產生一個流程，用於在團隊和機構中推廣成功的設計模式採用。
參考資料
- Brown、William J.；Malveau、Raphael C.；McCormick、Hays W. "Skip"；Mowbray、Thomas J. (1998)。《AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis》，John Wiley & Sons
- AntiPatterns：[url]www.antipatterns.com[/url]
- Wiki站點：[url]http://c2.com/cgi/wiki?AntiPattern[/url]
