軟件設(shè)計模式淺析論文

1、軟件設(shè)計模式淺析陳亞東（中原工學(xué)院 軟件學(xué)院，河南 鄭州 450000） 摘要：什么是軟件設(shè)計模式呢？其實廣義的來講，軟件設(shè)計模式是可解決一類軟件問題并且能反復(fù)使用的軟件設(shè)計方案；狹義的來講，軟件設(shè)計模式是對被用來在特定場景下解決一般設(shè)計問題的類和相互通信的對象的描述。是在類和對象的層次描述的可反復(fù)使用的軟件設(shè)計問題的解決方案。軟件設(shè)計模式通常描述了一組相互緊密作用的類與對象。在課堂學(xué)到的軟件設(shè)計模式，我學(xué)習(xí)的并不好，對各種模式的運用和實現(xiàn)，感覺簡單，但是要做起來還是有些難度。本文簡單講述了以面向?qū)ο蠹夹g(shù)為基礎(chǔ)的軟件設(shè)計模式的分析。關(guān)鍵詞：設(shè)計模式；設(shè)計方案；面向?qū)ο笾袊诸愄枺篢P311.5

2、 文獻標(biāo)志碼：ASoftware design patterns is analysedChenyadong（Zhongyuan University of Technology Software college，henan zhengzhou 450000）Abstract: What is a software design pattern? Actually, broadly speaking, the software design pattern is a type of the software can solve the problem and the repeated use

3、of the software design; Narrowly speaking, the software design pattern is to be used in specific scenarios and communicate with each other to solve the problem of general design of the description of the object. Is described in the level of the classes and objects can be repeated use of the software

4、 design of the solution of the problem. Software design patterns usually describes a set of mutually close function classes and objects.Learned in the class of software design pattern, Im not a very good learning, for the use of various patterns and implementation, feeling is simple, but want to do

5、or some difficulty. This article simply describes the software design based on object-oriented technology pattern analysis.Key words: design patterns; Design scheme; object-oriented 對于軟件設(shè)計模式，從上課到現(xiàn)在，我在頭腦中還沒有一個完整的概念，主要是因為我的基礎(chǔ)比較差，憑自身能力還不能寫出來一個項目。通過上網(wǎng)搜索，知道了什么是軟件設(shè)計模式，它是一套被反復(fù)使用，多數(shù)人知曉的，經(jīng)過分類編目的，代碼設(shè)計經(jīng)驗的總結(jié)，使用

6、設(shè)計模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性1。軟件設(shè)計模式分為基礎(chǔ)模式、委托模式、接口模式、代理模式、創(chuàng)建型模式、抽象工 廠模式、單例模式、生成器模式、工廠方法模式、原型模式、適配器模式等等。1、 設(shè)計模式模式是用來描述所交流的問題及解決方案的2,一個完整的設(shè)計模式主要由模式名稱、問題、解決方案、效果四個基本要素組成2。設(shè)計模式體現(xiàn)的是程序整體的一種構(gòu)思，所以有時候它也會出現(xiàn)在分析或者是概要設(shè)計階段中，設(shè)計模式的核心思想是通過增加抽象層，把變化部分從那些不變的部分中分離出來。這就是我所了解的設(shè)計模式。設(shè)計模式有五種原則，“開-閉”原則（OCP）、單一職責(zé)原則(SRP)、里

7、氏代換原則(LSP)、依賴倒置原則(DIP)和接口隔離原則(ISP)3，設(shè)計模式就是實現(xiàn)了上面所說的五種原則，從而達到了代碼復(fù)用、增加可維護性的目的。在設(shè)計模式經(jīng)典著作GOF95中，設(shè)計模式從應(yīng)用的角度上被分為三個大的類型，分別是創(chuàng)建型模式、結(jié)構(gòu)型模式和行為型模式。又根據(jù)模式的范圍分，模式既用于類又用于對象，類模式是處理類和子類之間的關(guān)系，這些關(guān)系通過繼承建立，是靜態(tài)的，在編譯時刻便確定下來了；對象模式是處理對象間的關(guān)系，這些關(guān)系在運行時刻是可以變化的，更具動態(tài)性。從某種意義上來說，幾乎所有模式都使用繼承機制，所以“類模式”只指那些集中于處理類間關(guān)系的模式，而大部分模式都屬于對象模式的范疇。2

8、、 設(shè)計模式的分類創(chuàng)建型設(shè)計模式是用來創(chuàng)建對象的模式，抽象了實例化過程，工廠模式、抽象工廠模式、單件模式、生成器模式、原型模式都屬于創(chuàng)建型設(shè)計模式。簡單來說一下創(chuàng)建型結(jié)構(gòu)模式有哪幾種模式吧，首先說一下工廠模式，工廠模式：客戶類和工廠類分開，消費者任何時候需要某種產(chǎn)品，只需要向工廠請求即可，消費者無須修改就可以接納新產(chǎn)品；缺點就是當(dāng)產(chǎn)品修改時，工廠類也要做出相應(yīng)的修改。比如：如何創(chuàng)建及如何向客戶端提供。抽象工廠模式：為一個產(chǎn)品族提供統(tǒng)一的創(chuàng)建接口，當(dāng)需要這個產(chǎn)品族的某一系列的時候，可以從抽象工廠中選出相應(yīng)的系列創(chuàng)建一個具體的工廠類。單件模式：保證一個類有且僅有一個實例，提供一個全局訪問點。生成器

9、模式：將復(fù)雜對象創(chuàng)建與表示分離，同樣的創(chuàng)建過程可創(chuàng)建不同的表示，允許用戶通過指定復(fù)雜對象類型和內(nèi)容來創(chuàng)建對象，用戶不需要知道對象內(nèi)部的具體構(gòu)建細(xì)節(jié)。原型模式：通過“復(fù)制”一個已經(jīng)存在的實例來返回新的實例（不新建實例）。被復(fù)制的實例就是“原型”，這個原型是可定制的。原型模式多用于創(chuàng)建復(fù)雜的或者耗時的實例，因為這種情況下，復(fù)制一個已經(jīng)存在的實例使程序運行更高效；或者創(chuàng)建值相等，只是命名不一樣的同類數(shù)據(jù)。這幾種模式老師也讓做過作業(yè)，做起來感覺也挺簡單的。結(jié)構(gòu)型模式討論的是類和對象的結(jié)構(gòu)，它采用繼承機制來組合接口或?qū)崿F(xiàn)（類結(jié)構(gòu)型模式），或者通過組合一些對象來實現(xiàn)新的功能（對象結(jié)構(gòu)型模式）。結(jié)構(gòu)型模式有

10、這幾種模式，組合模式：定義一個接口，使之用于單一對象，也可以應(yīng)用于多個單一對象組成的對象組。裝飾模式：給對象動態(tài)添加額外的職責(zé)，就好像給一個物體加上裝飾物，完善其功能。代理模式：在軟件系統(tǒng)中，有些對象有時候由于跨越網(wǎng)絡(luò)或者其他障礙，而不能夠或者不想直接訪問另一個對象，直接訪問會給系統(tǒng)帶來不必要的復(fù)雜性，這時候可以在客戶程序和目標(biāo)對象之間增加一層中間層，讓代理對象來代替目標(biāo)對象打點一切，這就是代理模式。享元模式：Flyweight是一個共享對象，它可以同時在不同上下文（Context）使用。外觀模式：外觀模式為子系統(tǒng)提供了一個更高層次、更簡單的接口，從而降低了子系統(tǒng)的復(fù)雜度，使子系統(tǒng)更易于使用和

11、管理。外觀承擔(dān)了子系統(tǒng)中類交互的責(zé)任。橋梁模式：橋梁模式的用意是將問題的抽象和實現(xiàn)分離開來實現(xiàn)，通過用聚合代替繼承來解決子類爆炸性增長的問題。適配器模式：將一個類的接口適配成用戶所期待的接口。一個適配器允許因為接口不兼容而不能在一起工作的類工作在一起，做法是將類自己的接口包裝在一個已存在的類中。對于這幾種模式，我理解的太籠統(tǒng)，也不太明白，只是根據(jù)這些定義來用心理解來消化。行為型設(shè)計模式著力解決的是類實體之間的通訊關(guān)系，希望以面向?qū)ο蟮姆绞矫枋鲆粋€控制流程。行為型設(shè)計模式種類比較多，其中觀察者模式和訪問者模式運用的比較多。模版模式：定義了一個算法步驟，并允許子類為一個或多個步驟提供實現(xiàn)。子類在不

12、改變算法架構(gòu)的情況下，可重新定義算法中某些步驟。觀察者模式：定義了對象之間一對多的依賴，當(dāng)這個對象的狀態(tài)發(fā)生改變的時候，多個對象會接受到通知，有機會做出反饋。迭代子模式：提供一種方法順序訪問一個聚合對象中各個元素, 而又不需暴露該對象的內(nèi)部表示。責(zé)任鏈模式：很多對象由每一個對象對其下一個對象的引用而連接起來形成一條鏈。請求在這個鏈上傳遞，直到鏈上的某一個對象決定處理此請求。發(fā)出這個請求的客戶端并不知道鏈上的哪一個對象最終處理這個請求，這使系統(tǒng)可以在不影響客戶端的情況下動態(tài)的重新組織鏈和分配責(zé)任。備忘錄模式：在不破壞封裝性的前提下，捕獲一個對象的內(nèi)部狀態(tài)，并在該對象之外保存這個狀態(tài)。這樣以后就可

13、將該對象恢復(fù)到原先保存的狀態(tài)。命令模式：將請求及其參數(shù)封裝成一個對象，作為命令發(fā)起者和接收者的中介，可以對這些請求排隊或記錄請求日志，以及支持可撤銷操作。狀態(tài)模式：允許一個“對象”在其內(nèi)部狀態(tài)改變的時候改變其行為，即不同的狀態(tài)，不同的行為。訪問者模式：表示一個作用于某對象結(jié)構(gòu)中的各元素的操作?？梢栽诓桓淖兏髟氐念惖那疤嵯露x作用于這些元素的新操作。解釋器模式：給定一個語言，定義它的文法的一種表示，并定義一個解釋器，這個解釋器使用該表示來解釋語言中的句子。中介者模式：用一個中介對象來封裝一系列的對象交互。策略模式：定義一組算法，將每個算法都封裝起來，并且使它們之間可以互換。策略模式使這些算法在

14、客戶端調(diào)用它們的時候能夠互不影響地變化。因為是學(xué)時太少的原因，老師講的模式并不多，這幾個模式好多都沒有講，我們只能根據(jù)一些書籍和資料來學(xué)習(xí)。3、 模式分析對于工廠模式，是最常見的一種模式之一。在面向?qū)ο缶幊讨? 常用的方法是用new操作符構(gòu)造對象實例，但在有些情況下，new操作符直接生成對象會帶來一些問題。創(chuàng)建對象之前必須清楚所要創(chuàng)建對象的類信息，但個別情況下無法達到此要求，譬如打開一個視頻文件需要一個播放器對象，但是用戶可能不知道具體播放器叫什么名字，需要系統(tǒng)分派給這個視頻文件一個合適的播放器，這種情況下用new運算符并不合適。許多類型對象的創(chuàng)造需要一系列步驟，比如需要計算或取得對象的初始設(shè)

15、置，需要選擇生成哪個子對象實例，在生成需要對象之前必須先生成一些輔助功能對象。在這些情況, 新對象的建立就是一個 “過程”，而不僅僅是一個操作。為了能方便地完成這些復(fù)雜的對象創(chuàng)建工作，可引入工廠模式 。工廠模式的實例分析：/EventFactory類publicclassEventFactory:LogFactorypublicoverrideEventLogCreate()returnnewEventLog();/FileFactory類publicclassFileFactory:LogFactorypublicoverrideFileLogCreate()returnnewFileLog

16、(); 客戶程序有效避免了具體產(chǎn)品對象和應(yīng)用程序之間的耦合，增加了具體工廠對象和應(yīng)用程序之間的耦合，在類內(nèi)部創(chuàng)建對象通常比直接創(chuàng)建對象更靈活，通過面向?qū)ο蟮氖址?，將具體對象的創(chuàng)建工作延遲到子類，提供了一種擴展策略，較好的解決了緊耦合問題。工廠模式客戶端程序：publicclassApppublicstaticvoidMain(stringargs)LogFactoryfactory=newEventFactory();/FileFactoryfactory=newFileFactory();Loglog=factory.Create();log.Write();對于抽象工廠模式，在軟件系統(tǒng)中，

17、經(jīng)常面臨“一系列相互依賴對象”的創(chuàng)建工作，由于需求變化，這“一系列相互依賴的對象”也要改變，如何應(yīng)對這種變化呢？如何像工廠模式一樣繞過常規(guī)的”new”，提供一種“封裝機制”來避免客戶程序和這種“多系列具體對象創(chuàng)建工作”的緊耦合呢？其中有一種說法就是可以將這些對象一個個通過工廠模式來創(chuàng)建。但是，既然是一系列相互依賴的對象，它們是有聯(lián)系的，每個對象都這樣解決，如何保證他們的聯(lián)系呢？所以運用抽象工廠模式，是一種有效的解決途徑。抽象工廠模式提供一個創(chuàng)建一系列相關(guān)或相互依賴對象的接口，而無需指定他們具體的類。適用于一個系統(tǒng)獨立于其產(chǎn)品創(chuàng)建、組合和表示時，一個系統(tǒng)由多個產(chǎn)品系列中的一個來配置時，強調(diào)一系列

18、相關(guān)產(chǎn)品對象的設(shè)計以便進行聯(lián)合時，提供一個產(chǎn)品類庫，只想顯示其接口而非實現(xiàn)時。抽象工廠模式的結(jié)構(gòu)，如下圖：圖1 抽象工廠模式的結(jié)構(gòu)抽象工廠模式與工廠模式的區(qū)別就在于工廠模式提供一個接口，用于創(chuàng)建相關(guān)和依賴對象的家族，而不需要明確指定具體類。抽象工廠模式允許客戶使用抽象接口來創(chuàng)建一組相關(guān)產(chǎn)品，而不需要關(guān)心具體實際產(chǎn)出的產(chǎn)品是什么。對于適配器模式，是將一個類的接口，轉(zhuǎn)換成客戶期望的另一個接口，適配器讓原本接口不兼容的類可以一起工作。打個比方說，一個team要為外界提供S類服務(wù)，但team里面沒有能夠完成此項任務(wù)的member，只有team外的A可以完成這項服務(wù)。為保證對外服務(wù)類別的一致性（提供S服

19、務(wù)），一是將A招安到team內(nèi)，負(fù)責(zé)提供S類服務(wù)，二是A不準(zhǔn)備接受招安，可安排B去完成這項任務(wù)，并讓B做好A的工作，讓B工作的時候向A請教，此時，B是一個復(fù)合體（提供S服務(wù)，是A的繼承弟子）。這種模式的使用過程是客戶通過目標(biāo)接口調(diào)用適配器的方法對適配器發(fā)出請求，適配器使用被適配者接口把請求轉(zhuǎn)換成被適配者的一個或者多個調(diào)用接口，客戶接收到調(diào)用的結(jié)果，但并未察覺這一切是適配器在起轉(zhuǎn)換作用。就是將一個類的接口轉(zhuǎn)換成客戶希望的另外一個接口，使得原本由于接口不兼容而不能一起工作的類可以一起工作。適配器模式有三種適用場合，一是使用一個已經(jīng)存在的類，而它的接口不符合要求，二是創(chuàng)建一個可以復(fù)用的類，該類可以與

20、其他不相關(guān)的類或不可預(yù)見的類（即那些接口可能不一定兼容的類）協(xié)同工作，三是使用一些已經(jīng)存在的子類，但不可能通過子類化以匹配各自接口。對象適配器可以適配它的父類接口。適配器模式還分為了累適配器和對象適配器兩種，這里就不再具體介紹了。適配器模式的優(yōu)點就是方便設(shè)計者自由定義接口，不用擔(dān)心匹配問題，而它的缺點是這個模式屬于靜態(tài)結(jié)構(gòu) ，由于只能單繼承，所以不適用于多種不同的源適配到同一個目標(biāo)。對于命令模式，將一個請求封裝為一個對象，可用不同請求對客戶進行參數(shù)化；對請求排隊或記錄請求日志，以及支持可撤消的操作。這種模式的適用性是抽象出待執(zhí)行的動作以參數(shù)化某對象，在不同時刻指定、排列和執(zhí)行請求，支持取消操作

21、，支持修改日志，用構(gòu)建在原語操作上的高層操作構(gòu)造一個系統(tǒng)。命令模式的實現(xiàn)：public class Receiver /接收者 public void action() System.out.println(“我在行動); public interface Command /抽象命令 public abstract void execute();public class ConcreteCommand implements Command /具體命令 Receiver rcv; /含有接收者的引用 ConcreteCommand(Receiver rcv) this.rcv=rcv; publ

22、ic void execute() rcv.action(); /執(zhí)行命令 public class Invoker /請求者 Command command; public void setCommand(Command command) mand=command; public void startExecuteCommand() command.execute(); public class Application /客戶程序 public static void main(String args) Receiver r=new Receiver(); Command command=new ConcreteCommand(r); Invoker i=new Invoker(); i.setCommand(command); i.startE