介紹 IBM Rational Software Architect

設計模式是經常發上的設計問題的解決方案。模式描述了如何利用一組類來解決問題——換句話說，模式為您的系統的現有部分提供一個概括的藍圖。模式不包含算法，相反地，它關注于類之間的關系。通過使用設計模式，您能夠利用已證實的導致更佳設計和更快實現的解決方案。設計模式還可以促進長期的代碼維護。設計模式的基本目標是：

• 使用接口
• 使用合成而不用繼承
• 封裝

對于設計模式為什么重要的不同問題，考慮一個管理列表的簡單實例。在計算機科學課程中，您曾學過不同類型的列表：數組、哈希影射、鏈表、堆棧、隊列等等。如果您用 Java 程序設計語言編過程序，您就很有可能使用過 Collection 接口和它的一些子類。那么，您會了解到所有的列表均有一個基本的操作：迭代。您總是想要對列表進行迭代以得到其中存儲的值。對于這樣的一個任務，我會使用簡單的設計模式，如 Iterator，它著重于迭代列表的一般方法，以避免每次要遍歷列表時重復構造。用于迭代數組（相對于 LinkedList）的具體算法留給設計模式的實現部分。

Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides —— 叫作 Gang of Four，使模式普及起來。他們的著作《Design Patterns: Elements Of Reusable Object-Oriented Software》是軟件架構師的必讀書籍。書中定義了 23 種設計模式，所有的模式都包含于 Rational Software Architect 中。（要了解更多 Gang of Four 敘述的設計模式的信息，參見本文底部的參考資料。）現今，幾乎每個大型的信息技術（information technology，IT）組織都采用了設計模式。Sun Microsystems 使用了許多設計模式，并將設計模式應用到 Java 和 Java 2 Platform Enterprise Edition (J2EE) 技術上。Server Side Web 站點是另一個很好的知識庫，在其中，開發人員可以對設計模式做出貢獻。

設計模式中的元素
設計模式由以下元素組成。您可以將此列表當作閱讀或撰寫設計模式的模板：

• 模式名稱：一個簡短的富有表現力的名稱
• 意圖：模式要做什么
• 通稱：該模式的其他名字
• 動機：問題及該模式如何解決問題的實例
• 適用性：該模式所應用的情景
• 結構：代表該模式的類圖
• 參與者：類及其職責的描述
• 協作：描述參與者之間的交互
• 結果：描述交替使用、設計選擇和使用該模式的影響

不論您是創建自己的模式，還是使用已經存在的模式，務必要密切地關注“適用性”部分。如果您在此部分中提供了足夠的細節，那么其他用戶將會很好地理解什么時候且如何使用您創建的設計模式。相反地，該部分將幫助您找到最適合具體設計問題的模式。

設計模式的類型
Rational Software Architect 包含所有 23 個 Gang of Four 模式。（但是，您還可以創建并添加自己的模式。）這些模式分成三個類別：

• 創建類，處理對象或類的創建
• 動作類，處理類或對象如何交互及分配職責
• 結構類，處理類或對象的組合

圖 1 描述了一個每個類別之下的模式的完整列表。

圖 1. Rational Software Architect 中的設計模式

本文介紹了如何在 Rational Software Architect 中實現三個基本的設計模式。本文的意圖不是使您成為設計模式的專家，而是向您介紹 Rational Software Architect 所具有的模式功能。

Rational Software Architect 中的設計模式
Rational Software Architect（IBM Software Development Platform 的一部分）允許架構師設計并維護應用程序體系結構。 該工具建立在 Eclipse 之上，因此開發人員和架構師可以利用 Rational Software Architect 中 Eclipse 平臺的可用特性。另外，該工具提供豐富的建模和體系結構設計及發現功能，超過典型的集成開發環境（IDE）所具有的特征。這是設計模式流行的原因。

注意：要了解更多關于 Eclipse 的信息，請參見參考資料部分。要了解更多關于 Rational Software Architect 的介紹信息，請參見我的文章“Introducing IBM Rational Software Architect：Improved usability makes software development easier”——也在參考資料部分。

為了展示在 Rational Software Architect 中使用設計模式是多么簡單的一件事，我將描述一個名為Singleton 模式的簡單模式。

注意：本文中我所討論的模式是為進行普通任務而隨機選擇的。

Singleton 模式
如其名稱所暗示的，當您想要特別類的僅僅一個實例時，才使用 Singleton 模式。例如，如果您想要為一些數據庫操作生成單鍵，那么您可以使用此創建類模式 —— 在這種情況下，如果您想要一個用于返回這些鍵的類實例。在其他實例中，此模式也是有用的，包括登錄和打印，例如，當您想要一個能夠每次訪問并控制一個特別打印機的類實例。

要想在 Rational Software Architect 中創建Singleton 模式的實例，就執行以下步驟。（在此實例中，我并沒有針對其他與此模式相關的問題，如保持同步以確保線程安全。）

1. 創建一個新的統一建模語言（Create a new Unified Modeling Language，UML）類圖，然后打開上圖 1 中顯示的模式瀏覽器。
2. 將Singleton 模式實例從模式瀏覽器中拖拽到 UML 類圖視圖中。
3. 在模式參數窗口中，定義一個參數，稱為 MySingleton（參見圖 2）。執行此操作將會在模型瀏覽器中生成一個Singleton 模式的實例。
4. 將實例拖拽到圖表上。
5. 為Singleton 模式創建私有屬性，稱為_instance。
6. 為Singleton 模式創建兩個方法：構造函數是私有的，且有一個公有的方法，稱為 getInstance()。
7. 利用 UML 到 Java 的轉換，為Singleton 模式生成代碼（參見清單 1）。

圖 2. 一個Singleton 模式的實例

            /*
            * Created on Nov 20, 2004
            *
            * TODO To change the template for this generated file, go to
            * Window - Preferences - Java - Code Style - Code Templates
            */
            /**
            * @author Kunal Mittal
            *
            * TODO To change the template for this generated type comment, go to
            * Window - Preferences - Java - Code Style - Code Templates
            * @uml.annotations
            * derived_abstraction="platform:/resource/DesignPatternsProject/BlankModel.emx
            * #_O5_0wDtjEdmuPoGm0fksdQ%2cuml2.Class%2cBlank+Model%3a%3aMySingleton"
            * @generated "UML to Java (com.ibm.xtools.transform.uml2.java.internal.UML2JavaTransform)"
            */
            public class MySingleton {
            /**
            * Comment for _instance
            * @generated "UML to Java (com.ibm.xtools.transform.uml2.java.internal.UML2JavaTransform)"
            */
            private Object _instance;
            /**
            *
            * @generated "UML to Java (com.ibm.xtools.transform.uml2.java.internal.UML2JavaTransform)"
            */
            private MySingleton() {
            // TODO Auto-generated constructor stub
            }
            /**
            *
            *@generated "UML to Java (com.ibm.xtools.transform.uml2.java.internal.UML2JavaTransform)"
            */
            public void getInstance() {
            // TODO Auto-generated method stub
            }
            }
            

注意：我將在本文的后部討論該模式的實例化。要了解更多關于創建 UML 類圖和 UML 到 Java 的轉換的信息，請參看我的文章“Introducing IBM Rational Software Architect: Improved usability makes software development easier”（參見 參考資料）。

那是個簡單的模式?，F在，我將為您展示一個稍微復雜的模式。

Factory 方法模式
Factory 方法模式是一個創建的模式，它定義一個用來創建對象的接口，而讓子類來決定實例化哪個類。 換句話說，Factory 方法令一個類實例化到其子類。當一個應用程序需要實例化一個未知類型的類時，此模式是很有用的。只有當應用程序實際上需要該類，而不是在編譯或運行時過程中，此類的類型才成為顯式的。接下來的實例更進一步地解釋了此概念。

模式使用了兩個類型的類：product 類和 creator 類。Creator 類用于定義創建產品對象實例的Factory 方法。product 和creator 類是抽象的。Concrete 類為它們各自的基類提供恰當的實現。Factory 方法模式由以下類組成：

• Creator：如同創造者的類
• ConcreteCreator：一個或多個具體的創造者
• Product：抽象的產品類
• ConcreteProduct：一個或多個具體產品
• FactoryMapping：將創建者映射到產品上

要創建Factory 方法模式的實例，執行同Singleton 模式相同的步驟。圖 3 顯示了我創建的實例。在該實例中，模式由以下類組成：

• Creator： Game
• ConcreteCreator： BasicGame、AdvancedGame
• Product： Map
• ConcreteProduct： Room、Door、Wall、Window
• Factory Mapping：創建從 Basic Game 到 Room、Door 和 Wall 的參數關系。創建從 Advanced Game 到所有具體產品的參數關系。

圖 3. 游戲 Factory 方法模式

注意：在您生成代碼并檢查之前，要知道您也需要為 Factory 方法模式添加適當的方法。

在此實例中，直到玩家選擇為止，Game 類才知道什么時候實例化具體的游戲類。在那時，Game 類需要適當地創建 BasicGame 或 AdvancedGame 類的實例。這是個典型的Factory 方法模式實例。

該模式的另一個實例是圖書館。圖書館有許多文檔，如書、手稿和雜志。如果您建立一個圖書館管理應用程序，直到用戶將文檔拿到圖書管理員桌子上，您才知道用戶要查看的文檔類型。作為練習，嘗試使用 Rational Software Architect 建立一個該模式的圖書館模型。

您已經看過了兩個創建的模式，現在讓我們看看如何在 Rational Software Architect 中使用動作類的模式。

責任鏈模式
責任鏈模式用于促進請求的發送者或創始人（客戶機）和接收請求的系統之間的松耦合。您會在以下情況使用責任鏈模式：

• 多于一個的類需要處理特別的請求
• 處理者的順序需要動態指定
• 不能顯式地指定請求的接收者

該模式允許您鏈接響應請求的對象?？蛻魴C將請求實例化，并將其作為處理者實例的參數進行傳遞。具體的處理者實現了一個獲得請求對象的操作，并為鏈中的下一個處理者維持一個參考標準。具體的處理者是從抽象的處理者擴展而來。該模型的元素是：

• Handler：一個抽象類
• ConcreteHandler：具體的處理者實例
• HandleRequest：請求處理者

舉一個批準過程的實例。在此情景下，客戶機（在此情況下，公司的會計部分）提交用于批準的預算。預算需要經三個人批準：首席財政官（Chief Financial Officer，CFO）、首席操作官（Chief Operating Officer，COO），和首席執行官（Chief Executive Officer，CEO）。圖 4 描述了該設計模式的一個簡單實例。在此實例中，用到的類是：

• Handler：批準者
• ConcreteHandler： CEO、COO、CFO
• HandleRequest：批準預算

圖 4. 批準過程的責任鏈模式實例

作為另一個實例，考慮客戶支持應用程序。當支持請求進入到 IT 部門，第一級支持團隊將首先進行處理。根據對該請求的分析，他們可能需要將該請求發給第二或第三級支持人員。嘗試在 Rational Software Architect 中使用責任鏈設計模式為該情境建模。

總結
設計模式是公共設計問題的可復用的解決方案。他們可以幫助您快速創建更易維護的軟件。Gang of Four 所描述的 23 個設計模式包含于 Rational Software Architect 中，且您可以將這些模式拖拽到圖表之上，并能如模式所描述地快速地設置您的類。Rational Software Architect 中的代碼生成特性允許您生成基于這些模式的代碼。此外，您還可以創建自己的模式，或實現其他人創建的模式。

在本文中，您見到了一些簡單的模式，以及如何使用 Rational Software Architect 來實現這些模式。雖然我隨機地選擇了三個設計模式——Singleton 模式、Factory 方法模式，和責任鏈模式 —— 但我建議您用 Rational Software Architect 實現一兩個其他的模式。您可以從結構類模式開始。另一個好的練習方法是在 Rational Software Architect 中實現您在一些 Web 站點上讀到或見到的設計模式，如 TheServerSide.com 站點或從 Sun Blueprints 中。