設計模式在軟件開發中的應用——2012年 11 月 25 日高級軟件工程課程小論文

摘要：設計模式一般是對某一類軟件設計問題提出的通用的解決方案，將設計模式引入軟件設計和開發過程，目的就在於充分利用已有的軟件開發經驗，甚至是已有的代碼框架。最近一些年，設計模式已經成爲軟件項目團體中最熱門的話題之一，而且常常在社區引發激烈的討論。

本文介紹了設計模式的概念、描述、法則、分類以及程序設計語言與設計模式的關係，以實際案例介紹設計模式在軟件開發中的應用,並在此基礎上提出了一些軟件設計與開發過程當中使用設計模式存在的問題。

關鍵詞：設計模式；軟件設計與開發；面向對象；

1 引言

面向對象的實質是一種系統建模技術，面向對象思想只是一種高級編程規範，咱們只有利用它，而且在總結和繼承前人開發經驗的基礎上使用有特點的面向對象軟件開發方法，纔可能充分地利用其優越性，來解決咱們系統的各類需求及需求變動。

模式是一種方案，利用這種方案，咱們能夠完成某項工做;模式也是一種途徑，經過這種途徑，咱們能夠達到某個目的；同時，模式也是一種技術，咱們必須獲取並利用有效的技術。設計模式也是一種模式，是一種完成某個目的或構思的方案。它要求使用某種面向對象提供的類及相關機制^[1]。

2 設計模式概述

2.1   設計模式概念

模式(pattern)的概念最先由建築大師 Christopher Alexander 於 20 世紀 70年代提出，應用於建築領域。20 世紀 80 年代中期由 Ward Cunningham 和 Kent Beck 將其思想引入到軟件領域，1994 年開始由 Hillside Group(由 Kent Beck 等發起成立)和 OOPSLA 聯合發起了國際程序設計模式語言大會(Patterns Languages of Program Design，簡稱 PloP 或 PloPD)，現在模式已成爲軟件工程領域內的一個熱門話題，其在計算機領域的影響超過了在建築界的影響^[2]。

GoF 在《設計模式：可複用面向對象軟件基礎》一書中概括出模式的四個基本要素：

1. 模式名稱（Pattern name）
   一個助記名，它用一兩個詞來描述模式的問題、解決方案和效果。命名一個新的模式增長了咱們的設計詞彙。設計模式容許咱們在較高的抽象層次上進行設計。基於一個模式詞彙表，咱們本身以及同事之間就能夠討論模式並在編寫文檔時使用它們。模式名能夠幫助咱們思考，便於咱們與其餘人交流設計思想及設計結果。找到恰當的模式名也是咱們設計模式編目工做的難點之一。
2. 問題（Problem）
   描述了應該在什麼時候使用模式。它解釋了設計問題和問題存在的來龍去脈，它可能描述了特定的設計問題，如怎樣用對象表示算法等。也可能描述了致使不靈活設計的類或對象結構。有時候，問題部分會包括使用模式必須知足的一系列先決條件。
3. 解決方案（solution）
   描述了設計的組成部分，它們之間的相互關係及各自的職責和協做方式。由於模式就像一個模板，可應用於多種不一樣場合，因此解決方案並不描述一個特定而具體的設計或實現，而是提供設計問題的抽象描述和怎樣用一個具備通常意義的元素組合（類或對象組合）來解決這個問題。
4. 效果（consequences）
   描述了模式應用的效果及使用模式應權衡的問題。儘管咱們描述設計決策時，並不總提到模式效果，但它們對於評價設計選擇和理解使用模式的代價及好處具備重要意義。軟件效果大多關注對時間和空間的衡量，它們也表述了語言和實現問題。由於複用是面向對象設計的要素之一，因此模式效果包括它對系統的靈活性、擴充性或可移植性的影響。

2.2  模式的描述

設計模式的描述方法有天然語言描述法、形式化語言描述法等、統一標記語言(UML)描述法。

天然語言描述法比較簡單、方便，但在現實與設計之間的過渡描述不夠流暢。形式化語言主要包括DisCO、LePUS、Lay0M、ADV/ADO、CDL、PDL、PDSP等，其中DISCo側重於描述設計模式中參與者的交互行爲。

統一建模語言 UML 是在多種面向對象建模方法的基礎上發展起來的建模語言，主要用於軟件密集型系統的建模。在多種面向對象建模方法流派並存和相互競爭的局面中，UML 樹起了統一的旗幟，使不一樣廠商開發的系統模型可以基於共同的概念，使用相同的表示法，呈現彼此一致的模型風格。並且它從多種方法中吸取了大量有用的建模概念，使它的概念和表示方法在規模上超過了以往任何一種方法，而且提供了容許用戶對語言作進一步的擴展機制。

2.3  模式的法則

在設計模式中，須要用到一些與 OOP 相關的法則，這些法則也是設計模式自身所依賴和體現的重要原則。經過使用這些法則，能夠消除系統間的耦合性，提升系統內的內聚性，使系統更加靈活和易於維護 ^[3] 。

1. 開閉法則(OCP)：對擴展開放,對修改關閉。
2. Liskov代換法則(LSP)：繼承必須確保超類擁有的性質子類中仍然成立。
3. 依賴反轉法則(DIP）：依賴抽象而不依賴具體。
4. 接口隔離法則(ISP)：不該強迫客戶端依賴於它們用不上的方法。
5. 單一職責法則(SRP）：一個類應該僅有一個緣由致使其變化。

2.4  模式的分類

    根據設計模式在粒度和抽象層次上各不相同，存在着衆多的設計模式，咱們按照模式的目的(即模式是用來完成什麼工做的)對模式進行分類，從而更好地分析和使用模式。模式依據其目的能夠分紅建立型 (Creational)、結構型(Struetural)、行爲型(Behavioral)三種^[4]。

1．建立型模式

社會化的分工愈來愈細，天然在軟件設計方面也是如此，所以對象的建立和對象的使用分開也就成爲了必然趨勢。由於對象的建立會消耗掉系統的不少資源，因此單獨對對象的建立進行研究，從而可以高效地建立對象就是建立型模式要探討的問題。這裏有6個具體的建立型模式可供研究，它們分別是：

簡單工廠模式（Simple Factory）；

工廠方法模式（Factory Method）；

抽象工廠模式（Abstract Factory）；

建立者模式（Builder）；

原型模式（Prototype）；

單例模式（Singleton）；

2．結構型模式

在解決了對象的建立問題以後，對象的組成以及對象之間的依賴關係就成了開發人員關注的焦點，由於如何設計對象的結構、繼承和依賴關係會影響到後續程序的維護性、代碼的健壯性、耦合性等。對象結構的設計很容易體現出設計人員水平的高低，這裏有7個具體的結構型模式可供研究，它們分別是：

外觀模式（Facade）；

適配器模式（Adapter）；

代理模式（Proxy）；

裝飾模式（Decorator）；

橋模式（Bridge）；

組合模式（Composite）；

享元模式（Flyweight）；

3．行爲型模式

在對象的結構和對象的建立問題都解決了以後，就剩下對象的行爲問題了，若是對象的行爲設計的好，那麼對象的行爲就會更清晰，它們之間的協做效率就會提升，這裏有11個具體的行爲型模式可供研究，它們分別是：

觀察者模式（Observer）；

狀態模式（State）；

策略模式（Strategy）；

職責鏈模式（Chain of Responsibility）；

命令模式（Command）；

訪問者模式（Visitor）；

調停者模式（Mediator）；

備忘錄模式（Memento）；

迭代器模式（Iterator）；

解釋器模式（Interpreter）；

2.5  程序設計語言與設計模式的關係

模式是不依賴於編程語言的^[5]。從某種程度上講，模式構成了一種語言，它比編程語言更進了一步，使開發人員能夠彼此交流設計思想。然而，認識到特定的編程語言在軟件系統的發展過程當中扮演着重要角色是很是重要的。如今，咱們必須考慮工具、庫以及他們提供的通用環境，特別是當咱們考慮使用象Java和C#這樣的新的面向對象程序設計語言時。這些語言不但提供了傳統的編程語言語法，並且還構造在虛擬機之上，而且帶有完整而豐富的庫或包，使得開發和重用更加容易。

3軟件設計與開發過程當中設計模式的運用實例

使用設計模式能爲軟件項目的設計與開發帶來很大的優點，而要實現將模式轉化爲優點，須要根據實際狀況，選擇正確的設計模式。正確的將設計模式運用到軟件設計與開發中，讓整個軟件的健壯性更強，讓開發速度大大提升，本文將介紹基於抽象工廠的通用數據庫訪問層，此數據庫訪問層經過抽象工廠設計模式實現了多種類型的數據庫的訪問(Oracle,Sqlserver,Mysql，Sqlite等)，大大方便了筆者的開發。

抽象工廠模式是類的建立模式之一, 其用意是定義一個建立產品對象的工廠接口, 將實際建立工做推遲到子類中。在工廠模式中, 核心的工廠類再也不負責全部產品的建立, 而是將具體建立工做交給子類去作。這個核心類僅負責給出具體工廠必須實現的接口, 而不接觸產品類被實例化的細節。這使工廠模式能夠容許系統在不修改工廠角色的狀況下引進新產品^[6]。

在基於.NET的實際的應用開發中ADO.NET數據訪問模型爲開發者提供瞭如下5個命名空間: System.Data.SqlClient,System.Data.odbc, System.Data.oracleC lient, System.Data.OleDb 和System.Data.SqlServerClient。分別用於訪問SQL Server, 託管空間中的ODBC (Open DataBase Connectivity)數據源、Oracle、OLEDB ( Object Linking and Embedding DataBase) 數據源以及在託管的環境下從基於ServerCE中的數據庫。所以, 根據工廠模式的設計思想, 將這幾個對象進行封裝, 造成一個含有這些對象公共方法的抽象類, 而沒必要針對不一樣的數據庫類型分別編程實現。應用程序僅須要爲客戶端提供一個通用的耦合, 並極大地提升了代碼的複用性和系統的擴展性。基於工廠模式的數據訪問層類圖如圖1所示。

圖 1基於抽象工廠模式的數據訪問層類圖

    由於版面所限，此圖只截取了SqlserverDBFactory,OracleDBFactory爲例，其餘數據庫類型，只須要相應的添加相似的工廠便可實現，使用快捷方便。

數據庫訪問層經過DBHelper類與外界聯繫，其餘類庫調用DBHelper對數據庫進行操做，DBHelper，建立DataBaseConnectEntity對象，建立對象的過程當中，根據配置文件中的數據庫類型，選擇相對於的數據庫工廠，對DBFactory進行實例化。返回與數據庫類型相對應的AdoHelper對象，AdoHelper對象提供了對數據庫的具體操做方法。

    應用設計模式和.NET平臺進行數據訪問層的設計，採用工廠模式思想實現了不一樣數據庫間的異構整合。

4 軟件設計與開發過程當中使用設計模式面臨的問題

設計模式（Design pattern）是一套被反覆使用、多數人知曉的、通過分類編目的、代碼設計經驗的總結。 毫無疑問，設計模式於己於他人於系統都是多贏的，設計模式使代碼編制真正工程化，設計模式是軟件工程的基石，如同大廈的一塊塊磚石同樣。雖然設計模式爲提升軟件開發效率以及可靠性提供了很美好的藍圖，然而，設計模式在實際軟件設計與開發過程當中的使用卻存在着一些須要克服的問題，如下列舉幾個問題：

(1) 代碼複用引發的問題

代碼複用本是軟件設計與軟件開發中很是優秀的特性，避免了重複製造輪子消耗的人力物力，而設計模式的存在更加便利了代碼的複用。然而，因爲一些疏忽或者理解上的誤差，代碼複用的過程當中忽略了一些可能由於BUG的可能，形成程序崩潰，甚至引起災難也不是不可能的。因此，在代碼複用的過程當中，必定要務必確認代碼複用是否合理正確，是否是存在複用的可行性。

(2) 模式選用正確性的問題

雖然不少問題都是能夠套用相應的設計模式進行設計，而後，不是運用了設計模式就是好的設計，若是對設計模式瞭解不夠透徹，或者對業務瞭解不夠深入，都狠容易形成設計模式使用不正確，影響設計的科學性,甚至影響軟件最終運行的正確性。

(3) 過分設計的問題

簡單是美，是軟件開發中最最重要的一個準則。不只體如今代碼簡單化方便實現，並且BUG減小，容易維護，因此，可以簡單實現的儘量簡單實現，這應該是軟件開發過程當中開發人員和設計人員應該遵循的第一準則。沒有必要複雜的業務或者功能，套用複雜的設計模式，這原本就是有悖設計模式的初衷的。然而一些模式發燒友，偶爾會出現爲了使用設計模式而使用設計模式的現象，不免出現過分設計，引發系統代碼冗長，難以維護，簡單業務複雜化等一些列本不應出現的問題。

4 結束語

設計模式是對特定問題通過無數次經驗總結後提出的可以解決它的優雅的方案。可是，若是想要真正使設計模式發揮最大做用，僅僅知道設計模式是什麼，以及它是如何實現的是很不夠的，由於那樣就不能使你對於設計模式有真正的理解，也就不可以在本身的設計中正確、恰當的使用設計模式。

設計模式並不只僅是一個有關特定問題的解決方案這個結果，它的意圖以及它的動機每每更重要，由於一旦咱們理解了一個設計模式的意圖、動機，那麼在設計過程當中，就很容易的發現適用於咱們本身的設計模式，從而大大簡化設計工做，而且能夠獲得一個比較理想的設計方案。

另外，在學習設計模式的過程當中，應該更加註意設計模式背後的東西，即具體設計模式所共有的的一些優秀的指導原則，基本上有兩點^[7]：

• 發現變化，封裝變化
• 優先使用組合（Composition），而不是繼承

若是注意從這些方面來學習、理解設計模式，就會獲得一些比單個具體設計模式自己更有用的知識，而且即便在沒有現成模式可用的狀況下，咱們也同樣能夠設計出一個好的系統來。

參考文獻

[1] 莫勇騰. 深刻淺出設計模式(C#/Java版)[M].北京：清華大學出版社，2006

[2] StevenJohnMetsker. C#設計模式[M].北京:中國電力出版社.2005

[3] 郭領豔. 軟件設計模式的研究及應用. 天津大學碩士學問論文[D],2005

[4] 柳小文. 設計模式研究及應用.中南大學碩士學問論文[D]，2007

[5] BrandonGlodfedder. 模式的樂趣[M].北京:清華大學出版社，2003

[6]金迪,陳曉玲,林和平.基於設計模式的.NET通用數據訪問層研究.吉林大學學報[D],2010

[7] 孫鳴. 使用設計模式改善程序結構,IBM開發者論壇 2001