系統(tǒng)分析與設(shè)計論文

1、軟件設(shè)計模式的研究及應(yīng)用摘 要：設(shè)計模式記錄己知的反復(fù)出現(xiàn)的問題，以及在特定上下文中對該問題的解決方案。 設(shè)計模式構(gòu)成了強(qiáng)大的復(fù)用機(jī)制，在快速的需求變化面前，有利于解決軟件的開發(fā)成本高， 質(zhì)量不夠理想，后期軟件修改與維護(hù)困難、總體成功率不高等問題。本文主要對設(shè)計模式的 關(guān)鍵技術(shù)展開研究，綜述了面向?qū)ο筌浖母鞣N設(shè)計模式，描述了各種模式之間的關(guān)系以及 它們在軟件，設(shè)計過程中的使用，并對設(shè)計模式的進(jìn)一步發(fā)展作了展望在系統(tǒng)開發(fā)中應(yīng)用 設(shè)計模式所獲得的收益是顯著的，應(yīng)用設(shè)計模式解決具體的設(shè)計問題的趨勢是普遍的。設(shè)計 模式給出的解決方案具有更好的復(fù)用性、可擴(kuò)展性和維護(hù)性，采用設(shè)計模式的應(yīng)用系統(tǒng)更能 滿足

2、這些非功能需求。關(guān)鍵字：設(shè)計模式；面向?qū)ο螅粡?fù)用1引言設(shè)計模式并不只出現(xiàn)在面向?qū)ο蟮南到y(tǒng)中，因此設(shè)計模式本身并不局限于面向?qū)ο笤O(shè)計 的范疇，也不局限于某一種編程語言。但鑒于面向?qū)ο蠹夹g(shù)的成熟和廣泛應(yīng)用以及本文所在 的項目小組的實際情況，本文中的設(shè)計模式僅限于面向?qū)ο蟮脑O(shè)計模式。20世紀(jì)60年代爆發(fā)了 “軟件危機(jī)”，采用傳統(tǒng)的軟件開發(fā)方法往往導(dǎo)致軟件質(zhì)量差， 可靠性不能得到保證，軟件成本增長居高不下，軟件的開發(fā)進(jìn)度難以控制，軟件開發(fā)周期長， 維護(hù)困難，維護(hù)費用不斷增加。這些弱點逐漸被人們認(rèn)識到，并開始尋找新的軟件開發(fā)方法。 面向?qū)ο蟮能浖_發(fā)方法首先提出于20世紀(jì)60年代后期，之后經(jīng)過了幾乎20

3、年的時間， 對象技術(shù)開始得到廣泛應(yīng)用。在20世紀(jì)90年代，面向?qū)ο筌浖こ坛蔀榱撕芏嚅_發(fā)軟件產(chǎn) 品及信息系統(tǒng)首選的軟件開發(fā)技術(shù)和方法。對象技術(shù)導(dǎo)致了復(fù)用，而程序構(gòu)件的復(fù)用又導(dǎo)致 了更快的軟件開發(fā)和高質(zhì)量的程序。復(fù)用為解決“軟件危機(jī)”提供了一種有效的途徑。但是，人們也認(rèn)識到要設(shè)計面向?qū)ο蟮能浖潜容^困難的，要設(shè)計可以復(fù)用的面向?qū)ο?的軟件就更加困難。而面向?qū)ο筌浖脑O(shè)計專家在幾十年的設(shè)計工作中己經(jīng)積累了相當(dāng)多的 設(shè)計經(jīng)驗，如果能在后續(xù)的面向?qū)ο蟮能浖O(shè)計中充分利用這些設(shè)計經(jīng)驗，將有助于人們設(shè) 計出好的甚至是可以良好復(fù)用的面向?qū)ο蟮能浖到y(tǒng)。幸運的是，設(shè)計模式能夠幫助軟件工 作者，它是被記錄下來的

4、面向?qū)ο蟮能浖O(shè)計經(jīng)驗，這些設(shè)計已被證實是優(yōu)雅的，成功的和 易于復(fù)用的。2設(shè)計模式概述2.1設(shè)計模式的概念關(guān)于設(shè)計模式的定義有很多種，本文僅列出了幾個具有代表性的、權(quán)威性的定義：定義1： Alexander給出的經(jīng)典定義是：每一個模式描述了一個在我們周圍不斷重復(fù)發(fā)生 的問題，以及該問題的解決方案的核心。這樣，你就能一次又一次的使用該方案而不必做重 復(fù)勞動。定義2： GoF的設(shè)計模式中這樣描述：設(shè)計模式是對被用來在特定場景下解決一般 設(shè)計問題的類和相互通信的對象的描述。這是面向?qū)ο蟮脑O(shè)計模式，也是本文研究的對象。 盡管設(shè)計模式不限于面向?qū)ο?，不限于設(shè)計階段，甚至不限于軟件開發(fā)領(lǐng)域，但說明這一點

5、是必要的。定義3：模式是被命名的有組織的信息，它捕獲了在一定語境（場景）中包含相關(guān)作用 力的問題的解決方案的本質(zhì)結(jié)構(gòu)和內(nèi)在含義，這種解決方案被證明是成功的。這樣的定義包 含三部分：相關(guān)的上下文、與上下文相關(guān)的作用力系統(tǒng)和解決問題的方案。從模式的這個定 義可以看出，只有相關(guān)上下文和各種作用力完全符合時，模式中的解決方案才是最優(yōu)的方案。 也就是說，模式是一種在權(quán)衡了各種利弊后的解決方案，一旦作用力之間的平衡被打破，這 個解決方案就可能不再成立。定義4：設(shè)計模式提供一個用于細(xì)化軟件系統(tǒng)的子系統(tǒng)或組件，或它們之間關(guān)系的圖式。 它描述通用組件的公共再現(xiàn)結(jié)構(gòu)，通用組件可以解決特定語境中的一個一般設(shè)計問題。

6、設(shè)計 模式是中等規(guī)模的模式。它們在規(guī)模上比體系結(jié)構(gòu)模式小，但又獨立于特定編程語言和范例。2.2設(shè)計模式的要素一般而言，一個模式有四個基本要素。（1）模式名稱（Patten Name）一個助記名，它用一兩個詞來描述模式的問題、解決方 案和效果。命名一個新的模式增加了我們的設(shè)計詞匯。設(shè)計模式允許我們在較高的抽象層次 上進(jìn)行設(shè)計?；谝粋€模式詞匯表，我們自己以及同事之間就可以討論模式并在編寫文檔時 使用它們。模式名可以幫助我們思考，便于我們與其他人交流設(shè)計思想及設(shè)計結(jié)果。找到恰 當(dāng)?shù)哪Ｊ矫彩俏覀冊O(shè)計模式編目工作的難點之一。（2）問題（Problem）描述了應(yīng)該在何時使用模式。它解釋了設(shè)計問題和問題

7、存在的前 因后果，它可能描述了特定的設(shè)計問題，如怎樣用對象表示算法等。也可能描述了導(dǎo)致不靈 活設(shè)計的類或?qū)ο蠼Y(jié)構(gòu)。有時候，問題部分會包括使用模式必須滿足的一系列先決條件。（3）解決方案（Solution）描述了設(shè)計的組成成分，它們之間的相互關(guān)系及各自的職責(zé) 和協(xié)作方式。因為模式就像一個模板，可應(yīng)用于多種不同場合，所以解決方案并不描述一個 特定而具體的設(shè)計或?qū)崿F(xiàn)，而是提供設(shè)計問題的抽象描述和怎樣用一個具有一般意義的元素 組合（類或?qū)ο蠼M合）來解決這個問題。（4）效果（Consequences）描述了模式應(yīng)用的效果及使用模式應(yīng)權(quán)衡的問題。盡管我 們描述設(shè)計決策時，并不總提到模式效果，但它們對于評價

8、設(shè)計選擇和理解使用模式的代價 及好處具有重要意義。軟件效果大多關(guān)注對時間和空間的衡量，它們也表述了語言和實現(xiàn)問 題。因為復(fù)用是面向?qū)ο笤O(shè)計的要素之一，所以模式效果包括它對系統(tǒng)的靈活性、擴(kuò)充性或 可移植性的影響，顯式地列出這些效果對理解和評價這些模式很有幫助。3設(shè)計模式分類軟件設(shè)計模式的分類有不同的方法。本文主要參考文獻(xiàn)1來進(jìn)行分類。根據(jù)模式是用來 完成什么工作的不同，可將設(shè)計模式分為創(chuàng)建型模式、結(jié)構(gòu)型模式、行為型模式三種。根 據(jù)模式是用于類還是用于對象，可將其分為類模式和對象模式。類模式處理類和子類之間的 關(guān)系，這些關(guān)系通過繼承建立，是靜態(tài)的，在編譯時刻便確定下來；對象模式處理對象間的 關(guān)系，

9、這些關(guān)系在運行時刻是可以變化的，更具有動態(tài)性。3.1創(chuàng)建型設(shè)計模式創(chuàng)建型模式與對象的創(chuàng)建有關(guān)，即描述怎樣創(chuàng)建一個對象，它隱藏對象創(chuàng)建的具體細(xì)節(jié)， 使程序代碼不依賴具體的對象。因此當(dāng)我們增加一個新對象時幾乎不需要修改代碼即可。創(chuàng) 建型類模式將對象的部分創(chuàng)建工作延遲到子類，而創(chuàng)建型對象模式則將它延遲到另一個對象 中。創(chuàng)建型類模式有Factory Method（工廠方法）模式，創(chuàng)建型對象模式包Abstract Factory （抽象工廠）、Builder（生成器）、Prototype （原型）、Singleton （單件）四種模式。創(chuàng)建型 模式中，Abstract Factory由工廠對象產(chǎn)生多個類

10、的對象；Builder是由這個工廠對象使用一 個相對復(fù)雜的協(xié)議，逐步創(chuàng)建一個相對復(fù)雜的產(chǎn)品；Prototype是由該工廠對象通過拷貝原型 對象來創(chuàng)建產(chǎn)品對象；Singleton確保一個類只創(chuàng)建一個實例；Factory Method是先生成所要 創(chuàng)建的對象的類的子類，即由其子類進(jìn)行實例化創(chuàng)建對象。上述模式中，Abstract Factory 與 Factory Method 的關(guān)系是：Abstract Factory 僅聲明一個 創(chuàng)建Product（產(chǎn)品）的接口，真正創(chuàng)建Product是由AbstractProduct類的子類ConcreteProduct 類來實現(xiàn)，實現(xiàn)辦法通常是為每一個Pro

11、duct定義一個Factory Method，而一個 ConcreteFactory（具體的工廠）將為每個產(chǎn)品重定義Factory Method以指定產(chǎn)品。當(dāng)然Abstract Factory中的ConcreteFactory也可以用Prototype模式來實現(xiàn)，即具體工廠使用產(chǎn)品系列中每 一個產(chǎn)品的原型實例來初始化，再通過復(fù)制原型來創(chuàng)建新產(chǎn)品；Abstract Factory與Builder 的區(qū)別是：Builder模式著重一步步構(gòu)造一個復(fù)雜對象，并在最后一步返回產(chǎn)品，而Abstract Factory著重于多個系列的產(chǎn)品對象，其產(chǎn)品是立即可見的。例如：單件模式也稱為單例模式、單子模式，是使

12、用最廣泛的設(shè)計模式之一。其意圖是 保證一個類僅有一個實例，并提供一個訪問它的全局訪問點，該實例被所有程序模塊共享。 有很多地方需要這樣的功能模塊，如系統(tǒng)的日志輸出，GUI應(yīng)用必須是單鼠標(biāo)，MODEM的 聯(lián)接需要一條且只需要一條電話線，操作系統(tǒng)只能有一個窗口管理器，一臺PC連一個鍵盤 等等。在單例模式的實現(xiàn)過程中，需要注意如下三點：（1）單例類的構(gòu)造函數(shù)為私有；（2）提供一個自身的靜態(tài)私有成員變量；（3）提供一個公有的靜態(tài)工廠方法。單例模式的優(yōu)點：（1）提供了對唯一實例的受控訪問。因為單例類封裝了它的唯一實例，所以它可以嚴(yán) 格控制客戶怎樣以及何時訪問它，并為設(shè)計及開發(fā)團(tuán)隊提供了共享的概念。（2）

13、由于在系統(tǒng)內(nèi)存中只存在一個對象，因此可以節(jié)約系統(tǒng)資源，對于一些需要頻繁 創(chuàng)建和銷毀的對象，單例模式無疑可以提高系統(tǒng)的性能。（3）允許可變數(shù)目的實例。我們可以基于單例模式進(jìn)行擴(kuò)展，使用與單例控制相似的 方法來獲得指定個數(shù)的對象實例。單例模式的缺點：（1）由于單例模式中沒有抽象層，因此單例類的擴(kuò)展有很大的困難。（2）單例類的職責(zé)過重，在一定程度上違背了 “單一職責(zé)原則”因為單例類既充當(dāng)了 工廠角色，提供了工廠方法，同時又充當(dāng)了產(chǎn)品角色，包含一些業(yè)務(wù)方法，將產(chǎn)品的創(chuàng)建和 產(chǎn)品的本身的功能融合到一起。（3）濫用單例將帶來一些負(fù)面問題，如為了節(jié)省資源將數(shù)據(jù)庫連接池對象設(shè)計為單例 類，可能會導(dǎo)致共享連接池

14、對象的程序過多而出現(xiàn)連接池溢出；現(xiàn)在很多面向?qū)ο笳Z言（如 Java、C#）的運行環(huán)境都提供了自動垃圾回收的技術(shù)，因此，如果實例化的對象長時間不被 利用，系統(tǒng)會認(rèn)為它是垃圾，會自動銷毀并回收資源，下次利用時又將重新實例化，這將導(dǎo) 致對象狀態(tài)的丟失。3.2結(jié)構(gòu)型設(shè)計模式結(jié)構(gòu)型模式處理類或?qū)ο蟮慕M合，即描述類和對象之間怎樣組織起來形成大的結(jié)構(gòu)，從 而實現(xiàn)新的功能。結(jié)構(gòu)型類模式采用繼承機(jī)制來組合類，如Adapter （適配器類）模式；結(jié) 構(gòu)型對象模式則描述了對象的組裝方式，如Adapter （適配器對象）模式、Bridge （橋接） 模式、Composite （組合）模式、Decorator （裝飾）

15、模式、Facade （外觀）模式、Flyweight （享元）模式、Proxy （代理）模式。結(jié)構(gòu)型模式中，Adapter是將一個類的接口轉(zhuǎn)換成用戶 希望的另外一個接口； Bridge是將產(chǎn)品的抽象接口部分與具體實現(xiàn)部分分離；Composite是 將對象組合成樹型結(jié)構(gòu)以表示“部分一整體”的層次結(jié)構(gòu)；Decorator動態(tài)地給一個對象增 加一些額外的職責(zé)；Facade是為子系統(tǒng)中的一組接口提供一個一致的界面；Flyweight使用 共享技術(shù)支持大量細(xì)粒度對象；Proxy則是為其他對象提供一種代理以控制對這個對象的訪 問。上述模式中，Adapter與Bridge的區(qū)別是：Bridge目的是將接口部

16、分和實現(xiàn)部分分離， 從而對它們可以較為容易也相對獨立的加以改變，而Adapter則意味著要改變一個已有對象 的接口； Decorator與Adapter的區(qū)別是：Decorator模式增強(qiáng)了對象的功能而又不改變對象 的接口，但Adapter模式將給對象一個全新的接口； Proxy與Adapter的區(qū)別是：Proxy提供 的是與其實體相同的接口，即在不改變接口的條件下，為另一個對象提供代理，而Adapter 為其所適配的對象提供了一個不同的接口。例如：組合模式是將對象組合成樹形結(jié)構(gòu)以表示“部分一整體”的層次結(jié)構(gòu)，Composite 使得客戶對單個對象和復(fù)合對象的使用具有一致性。使用場合：當(dāng)需要描

17、述的對象具有“遞歸組合”、且希望用戶忽略基本對象與組合對象 的區(qū)別時，可使用本模式。組合模式結(jié)構(gòu)圖如圖3-1所示。圖3-1組合模式結(jié)構(gòu)圖3.3行為型設(shè)計模式行為型設(shè)計模式描述算法以及對象之間的任務(wù)（職責(zé)）分配，它所描述的不僅僅是類或 對象的設(shè)計模式，還有它們之間的通訊模式。這些模式刻畫了在運行時刻難以跟蹤的復(fù)雜的 控制流。行為型類模式使用繼承機(jī)制在類間分派行為，如Template Method（模板方法）模 式和Interpreter （解釋器）模式；行為型對象模式使用對象復(fù)合而不是繼承，它描述一組對 象怎樣協(xié)作完成單個對象所無法完成的任務(wù)，如Chain of Reponsibility （職

18、責(zé)鏈）模式、 Command （命令）模式、Iterator （迭代器）模式、Mediator （中介者）模式、Memento （備 忘錄）模式、Observer （觀察者）模式、State （狀態(tài)）模式、Strategy （策略）模式、Visitor （訪問者）模式。行為型模式中，Chain of Reponsibility模式是將處理某個請求的對象連成一條鏈，用戶 可以沿著這條鏈傳遞該請求，直到有一個對象處理它為止；Command模式是將一個請求封 裝成一個對象，從而可用不同的請求對客戶進(jìn)行參數(shù)化；Interpreter模式描述的是如何為某 個語言定義文法，如何在該語言中表示一個句子以及如

19、何解釋這些句子；Iterator模式提供 一種方法順序訪問一個聚合中的各個元素而又不暴露該對象的內(nèi)部表示；Mediator是用一個 中介對象來封裝一系列復(fù)雜對象的交互，中介者使各對象不需要顯示的相互引用；Memento 是在不破壞封裝性的前提下，捕獲一個對象的內(nèi)部狀態(tài)并在該對象之外保存這個狀態(tài)，這樣 以后就可將該對象恢復(fù)到原先某一個狀態(tài)；Observer是定義對象間的一種一對多的依賴關(guān) 系，當(dāng)一個對象的狀態(tài)發(fā)生改變時，所有依賴于它的對象都得到通知，并自動更新；State 模式是允許一個對象在其內(nèi)部狀態(tài)改變時改變它的行為；Strategy定義一系列的封裝算法， 把他們一個個封裝起來，并使它們可以

20、相互替換；Template Method是定義一個操作中的算 法的構(gòu)架，而將一些步驟延遲到子類中（即一次性實現(xiàn)一個算法的不變部分，并將可變的行 為留給子類來實現(xiàn)）；Visitor模式是使在不改變各元素類的前提下定義作用于這些元素的新 操作。上述行為模式之間是相互補(bǔ)充的關(guān)系，例如Iterator可以遍歷一個聚合，而Visitor可以 對聚合的每一個元素進(jìn)行一個新操作。行為型模式和其他類型的模式也能很好的協(xié)同工作， 如一個使用Composite模式的系統(tǒng)可以使用Iterator進(jìn)行遍歷或用一個Visitor對該復(fù)合的個 別元素進(jìn)行一些新操作。例如：模板方法模式(Template Method Pa

21、ttern)： 一個操作中算法的骨架(the skeleton of an algorithm)，而將一些步驟延遲到子類中，模板方法使得子類可以不改變一個算法的結(jié)構(gòu)即 可重定義該算法的某些特定步驟。模板方法是一種類行為型模式。3.4各種模式之間的關(guān)系A(chǔ)bstract FactoryFactciry MethodBuilderProlcHypcSingleton類只有CommandMediatorTemplate MethodTemplate MethodChain of RcsponsibiliryIteniilor如上所述，創(chuàng)建型模式與對象的創(chuàng)建有關(guān)，結(jié)構(gòu)型模式處理類和對象的組合，行為型模

22、式描述算法以及對象之間的任務(wù)分配。因此所有模式之間都是通過類或?qū)ο蟮膭?chuàng)建、組合或 通訊發(fā)生聯(lián)系。圖3-2顯示出各模式之間的協(xié)作關(guān)系。Abstract FactoryFactciry MethodBuilderProlcHypcSingleton類只有CommandMediatorTemplate MethodTemplate MethodChain of RcsponsibiliryIteniilorMcmcntFacadeMcmcntFacadeVisitorStrategy定義對象的新操作InterpreterI對焰定語言1進(jìn)行解釋口提供一致界面Bridger共獨種設(shè)計模式與給對鼻添加新的

23、聊責(zé)FlyweightComposite-6-ProxyDecoratorAdapterBridger共獨種設(shè)計模式與給對鼻添加新的聊責(zé)FlyweightComposite-6-ProxyDecorator4結(jié)束語模式這一概念盡管很早就已經(jīng)存在，并且其中的很多方法（模式）在實際的軟件設(shè)計中 已經(jīng)使用，但真正系統(tǒng)地整理、分類以形成一種理論始于Erich Gamma的博士論文Gam91， Gam92 的部分工作，這個時間并不很長，國內(nèi)研究軟件設(shè)計模式的時間則更短。在國外， 設(shè)計模式研究工作進(jìn)展很快，人們不斷總結(jié)出新的模式，并且很多軟件開發(fā)工具和環(huán)境增加 了對他們的支持，有些研究機(jī)構(gòu)還設(shè)想將設(shè)計模式

24、用形式化表示以讓機(jī)器自動生成代碼，一 些類庫正在被開發(fā)以支持設(shè)計模式的實現(xiàn)（如JAVA在其標(biāo)準(zhǔn)類庫中提供了這樣一些支持）， 除此之外，他們還提出了軟件體系結(jié)構(gòu)模式（Architectural Patterns）、代碼模式（Idioms，或 coding patterns）以及分布式系統(tǒng)設(shè)計模式（Distribute Design patterns）、實時系統(tǒng)設(shè)計模式 （Real-Time Design Patterns）等等，具體可參見文獻(xiàn)2、3和4。本文描述了設(shè)計模式在 設(shè)計可重用性面向?qū)ο筌浖械闹匾浴⒏鞣N軟件設(shè)計模式的概念和它們之間的關(guān)系，以及 如何選擇和使用這些模式。通過閱讀本文能對軟件設(shè)計模式有一個初步的理解，但是要真正 理解這些模式的目的、結(jié)構(gòu)、模式參與者、參與者之間的協(xié)作以及使用這些模式的效果，還 必須研究和參考參考文獻(xiàn)1，該書對此作了詳細(xì)