軟件架構(gòu)的設(shè)計模式

1、軟件架構(gòu)設(shè)計模式隨著面向?qū)ο蠹夹g(shù)的發(fā)展和廣泛應(yīng)用，設(shè)計模式不再是一個新興的名詞，它已逐步成為系統(tǒng)架構(gòu)人員、設(shè)計人員、分析人員以及程序開發(fā)人員所需掌握的基本技能之一。設(shè)計模式已廣泛應(yīng)用于面向?qū)ο蟮脑O(shè)計和開發(fā)，成為面向?qū)ο箢I(lǐng)域的一個重要組成部分。設(shè)計模式通?？煞譃槿悾簞?chuàng)建型模式、結(jié)構(gòu)型模式和行為型模式。創(chuàng)建型模式概述創(chuàng)建型模式(CreationalPattern)對類的實例化過程及對象的創(chuàng)建過程進(jìn)行了抽象，能夠使軟件模塊做到與對象的創(chuàng)建和組織無關(guān)。創(chuàng)建型模式隱藏了對象的創(chuàng)建細(xì)節(jié)，通過隱藏對象如何被創(chuàng)建和組合在一起達(dá)到使整個系統(tǒng)獨立的目的。在掌握創(chuàng)建型模式時，需要回答以下三個問題：創(chuàng)建什么(Wha

2、t)、由誰創(chuàng)建(Who)和何時創(chuàng)建(When)。創(chuàng)建型模式主要包括簡單工廠模式、工廠方法模式、抽象工廠模式、建造者模式、原型模式、單例模式。以下介紹其中使用頻率較高的幾種模式，包括簡單工廠模式、工廠方法模式、抽象工廠模式、單例模式。1.1簡單工廠模式簡單工廠模式(SimpleFatoryPattern)，又稱靜態(tài)工廠方法模式(StaticFactotyMethodPattern)，屬于類創(chuàng)建型模式。在簡單工廠模式中，定義一個類,可以根據(jù)參數(shù)的不同返回不同的類的實例，這些類具有公共的父類和一些公共的方法。簡單工廠模式不屬于GoF設(shè)計模式，它是最簡單的工廠模式。簡單工廠模式專門定義一個類來負(fù)責(zé)創(chuàng)建

3、其他類的實例，這個類稱為工廠類，被創(chuàng)建的實例通常都具有共同的父類。在簡單工廠模式中，工廠類包含必要的判斷邏輯，決定在什么時候創(chuàng)建哪一個產(chǎn)品類實例，客戶端可以免除直接創(chuàng)建產(chǎn)品對象的責(zé)任，而僅僅“消費”產(chǎn)品，簡單工廠模式通過這種方式實現(xiàn)了對責(zé)任的劃分。但是由于工廠類集中了所有產(chǎn)品創(chuàng)建邏輯，一旦不能正常工作，整個系統(tǒng)都要受到影響；同時系統(tǒng)擴展較為困難，一旦添加新產(chǎn)品就不得不修改工廠邏輯，違反了開閉原則，并造成工廠邏輯過于復(fù)雜。正因為簡單工廠模式存在種種問題，一般只將它作為學(xué)習(xí)其他工廠模式的入門，當(dāng)然在一些并不復(fù)雜的環(huán)境下也可以直接使用簡單工廠模式。1.2工廠方法模式工廠方法模式(FactoryMet

4、hodPattern)也稱為工廠模式，又稱為虛擬構(gòu)造器(VirtualConstruetor)模式或多態(tài)模式，屬于類創(chuàng)建型模式。在工廠方法模式中，父類負(fù)責(zé)定義創(chuàng)建對象的公共接口，而子類則負(fù)責(zé)生成具體的對象，這樣做的目的是將類的實例化操作延遲到子類中完成，即由子類來決定究竟應(yīng)該實例化(創(chuàng)建)哪一個類。在工廠方法模式中，工廠方法用來創(chuàng)建客戶所需要的產(chǎn)品，同時還向客戶隱藏了哪種具體產(chǎn)品將被實例化這一細(xì)節(jié)。工廠方法模式的核心是抽象工廠類，各種具體工廠類繼承抽象工廠類并實現(xiàn)在抽象工廠類中定義的工廠方法，從而使得客戶只需要關(guān)心抽象產(chǎn)品和抽象工廠，完全不用理會返回的是哪一種具體產(chǎn)品，也不用關(guān)心它是如何被具體

5、工廠創(chuàng)建的。在系統(tǒng)加入新產(chǎn)品時，無須修改抽象工廠和抽象產(chǎn)品提供的接口，無須修改客戶端，也無須修改其他具體工廠和具體產(chǎn)品，而只要添加一個具體工廠和具體產(chǎn)品即可，這樣，系統(tǒng)的可擴展性也就變得非常好，符合開閉原則。但是在添加新產(chǎn)品時，需要編寫新的具體產(chǎn)品類，而且還要提供與之對應(yīng)的具體工廠類，難免會增加系統(tǒng)類的個數(shù)，增加系統(tǒng)的開銷。在以下情況中可以考慮使用工廠方法模式:1)當(dāng)客戶程序不需要知道使用對象的創(chuàng)建過程；2)客戶程序使用的對象存在變動的可能，或者根本就不知道使用哪一個具體的對象。1.3抽象工廠模式抽象工廠模式(AbstraetFactoryPattern)是所有形式的工廠模式中最為抽象和最具一

6、般性的一種形態(tài)。抽象工廠模式提供了一個創(chuàng)建一系列相關(guān)或相互依賴對象的接口，而無須指定它們具體的類。抽象工廠模式又稱為Kit模式，屬于對象創(chuàng)建型模式。抽象工廠模式包含如下角色：抽象工廠、具體工廠、抽象產(chǎn)品、具體產(chǎn)品。抽象工廠模式隔離了具體類的生成，使得客戶并不需要知道什么被創(chuàng)建。由于這種隔離，更換一個具體工廠就變得相對容易。所有的具體工廠都實現(xiàn)了抽象工廠中定義的那些公共接口，因此只需改變具體工廠的實例，就可以在某種程度上改變整個軟件系統(tǒng)的行為。另外，應(yīng)用抽象工廠模式可以實現(xiàn)高內(nèi)聚低耦合的設(shè)計目的,因此抽象工廠模式得到了廣泛的應(yīng)用；當(dāng)一個產(chǎn)品族中的多個對象被設(shè)計成一起工作時，它能夠保證客戶端始終只

7、使用同一個產(chǎn)品族中的對象。這對一些需要根據(jù)當(dāng)前環(huán)境來決定其行為的軟件系統(tǒng)來說，是一種非常實用的設(shè)計模式；增加新的具體工廠和產(chǎn)品族很方便，無須修改已有系統(tǒng)，符合開閉原則。但是抽象工廠模式也存在一些缺點，在添加新的產(chǎn)品對象時，難以擴展抽象工廠來生產(chǎn)新種類的產(chǎn)品，這是因為在抽象工廠角色中規(guī)定了所有可能被創(chuàng)建的產(chǎn)品集合，要支持新種類的產(chǎn)品就意味著要對該接口進(jìn)行擴展，而這將涉及到對抽象工廠角色及其所有子類的修改,顯然會帶來較大的不便；開閉原則的傾斜性（增加新的工廠和產(chǎn)品族容易，增加新的產(chǎn)品等級結(jié)構(gòu)麻煩）。以下情況可以考慮使用抽象工廠模式:1）一個系統(tǒng)不應(yīng)當(dāng)依賴于產(chǎn)品類實例如何被創(chuàng)建、組合和表達(dá)的細(xì)節(jié)；2

8、）系統(tǒng)中有多于一個的產(chǎn)品族，而每次只使用其中某一個產(chǎn)品族；3）屬于同一個產(chǎn)品族的產(chǎn)品將在一起使用，這一約束必須在系統(tǒng)的設(shè)計中體現(xiàn)出來。4）系統(tǒng)提供一個產(chǎn)品類的庫，所有的產(chǎn)品以同樣的接口出現(xiàn)，從而使客戶端不依賴于具體實現(xiàn)。例如在Java語言的AWT（抽象窗口工具包）中就使用了抽象工廠模式來實現(xiàn)在不同的操作系統(tǒng)中應(yīng)用程序呈現(xiàn)與所在操作系統(tǒng)一致的外觀界面。1.4單例模式單例模式（SingletonPattern）確保某一個類只有一個實例，而且向這個系統(tǒng)提供這個實例。單例模式的三個要點：某個類只能有一個實例；它必須自行創(chuàng)建這個實例；必須自行向這個系統(tǒng)提供這個實例。單例模式依據(jù)實例化時機的不同，分為兩種

9、模型：餓漢式單例和懶漢式單例。單例模式也是一種比較常見的設(shè)計模式，它有三個方面的作用：1）控制資源的使用，通過線程同步來控制資源的并發(fā)訪問；2）控制實例產(chǎn)生的數(shù)量，達(dá)到節(jié)約資源的目的。3）作為通信媒介使用，也就是數(shù)據(jù)共享，它可以在不建立直接關(guān)聯(lián)的條件下，讓多個不相關(guān)的兩個線程或者進(jìn)程之間實現(xiàn)通信。當(dāng)系統(tǒng)要求一個類只有一個實例時可使用單例模式，單例模式為系統(tǒng)提供了唯一實例的訪問，并且可以對單例模式進(jìn)行擴展獲得可變數(shù)目的實例，即多例模式。結(jié)構(gòu)型模式概述結(jié)構(gòu)型模式（StrueturalPattern）描述如何將類或者對象結(jié)合在一起形成更大的結(jié)構(gòu)。結(jié)構(gòu)型模式可以描述兩種不同的東西：類與類的實例（即對象

10、）。結(jié)構(gòu)型模式可以分為類結(jié)構(gòu)型模式和對象結(jié)構(gòu)型模式。結(jié)構(gòu)型模式包括適配器模式、橋接模式、組合模式、裝飾模式、外觀模式、享元模式和代理模式7種，以下只介紹適配器模式、組合模式、外觀模式和代理模式。2.1適配器模式適配器模式（AdapterPattern）將一個接口轉(zhuǎn)換成客戶希望的另一個接口，從而使接口不兼容的那些類可以一起工作，其別名為包裝器（Wrapper）。適配器模式可以作為類結(jié)構(gòu)型模式，也可以作為對象結(jié)構(gòu)型模式。適配器模式具有如下優(yōu)點：1）將目標(biāo)類和適配者類解耦，通過引入一個適配器類來重用現(xiàn)有的適配者類，而無須修改原有代碼；2）增加了類的透明性和復(fù)用性，將具體的實現(xiàn)封裝在適配者類中，對于客

11、戶端類來說是透明的，而且提高了適配者的復(fù)用性；3）靈活性和擴展性都非常好，通過使用配置文件，可以很方便地更換適配器，也可以在不修改原有代碼的基礎(chǔ)上增加新的適配器類，完全符合開閉原則。同時適配器也有如下缺點：1）對于Java、C#等不支持多重繼承的語言，一次最多只能適配一個適配者類，而且目標(biāo)抽象類只能為抽象類，不能為具體類，其使用有一定的局限性，不能將一個適配者類和它的子類都適配到目標(biāo)接口；2）與類適配器模式相比，要想置換適配者類的方法就不容易。如果一定要置換掉適配者類的一個或多個方法，就只好先做一個適配者類的子類，將適配者類的方法置換掉，然后再把適配者類的子類當(dāng)做真正的適配者進(jìn)行適配，實現(xiàn)過程

12、較為復(fù)雜。適配器模式適用環(huán)境：1）系統(tǒng)需要使用現(xiàn)有的類，而這些類的接口不符合系統(tǒng)的需要；2）想要建立一個可以重復(fù)使用的類，用于與一些彼此之間沒有太大關(guān)聯(lián)的一些類，包括一些可能在將來引進(jìn)的類一起工作；3）兩個類所做到事情相同或者相似，但是具有不同的接口的時候，和客戶要求不符合的時候；4）舊的系統(tǒng)開發(fā)的類已經(jīng)實現(xiàn)了一些功能，但是客戶端卻只能以另外接口的形式訪問，但是不希望手動更改原有的類；5）使用第三方組件，組件接口定義和自己定義的不同，不希望修改自己定義的接口，但是要使用第三方組件接口的功能。2.2組合模式在組合模式中（CompositePattern）將對象組合成樹形結(jié)構(gòu)以表示部分-整體的層次

13、結(jié)構(gòu)。組合模式使得用戶對單個對象和組合對象的使用具有一致性。組合模式基本遵循了依賴倒置原則，方便系統(tǒng)進(jìn)行擴展；可以清楚地定義分層的復(fù)雜對象，表示對象的全部或部分層次，使得增加新部件也更容易，提供了對象管理的靈活接口。其對樹形結(jié)構(gòu)的控制有神奇的功效。但是組合模式使得設(shè)計變得更加抽象。組合模式的適用環(huán)境：1）想表示一個對象整體或部分層次；2）想讓客戶能夠忽略不同對象的層次的變化；3）對象的結(jié)構(gòu)是動態(tài)的并且復(fù)雜程度不一樣，但客戶需要一致地處理它們；4）維護和展示部分-整體關(guān)系的場景，如樹形菜單、文件和文件夾管理。2.3外觀模式外觀模式（FacadePattern）要求外部與一個子系統(tǒng)的通信必須通過一

14、個統(tǒng)一的外觀對象進(jìn)行，為子系統(tǒng)中的一組接口提供一個一致的界面，外觀模式定義了一個高層接口，這個接口使得這一子系統(tǒng)更加容易使用。外觀模式又稱為門面模式，它是一種對象結(jié)構(gòu)型模式。外觀模式有如下優(yōu)點：1）對客戶屏蔽子系統(tǒng)組件，減少了客戶處理的對象數(shù)目并使得子系統(tǒng)使用起來更加容易。通過引入外觀模式，客戶代碼將變得很簡單，與之關(guān)聯(lián)的對象也很少。2）實現(xiàn)了子系統(tǒng)與客戶之間的松耦合關(guān)系，這使得子系統(tǒng)的組件變化不會影響到調(diào)用它的客戶類，只需要調(diào)整外觀類即可。3）降低了大型軟件系統(tǒng)中的編譯依賴性，并簡化了系統(tǒng)在不同平臺之間的移植過程因為編譯一個子系統(tǒng)一般不需要編譯所有其他的子系統(tǒng)。一個子系統(tǒng)的修改對其他子系統(tǒng)沒

15、有任何影響，而且子系統(tǒng)內(nèi)部變化也不會影響到外觀對象。4）只是提供了一個訪問子系統(tǒng)的統(tǒng)一入口，并不影響用戶直接使用子系統(tǒng)類。同時外觀模式也有如下缺點：1）不能很好地限制客戶使用子系統(tǒng)類，如果對客戶訪問子系統(tǒng)類做太多的限制則減少了可變性和靈活性。2）在不引入抽象外觀類的情況下，增加新的子系統(tǒng)可能需要修改外觀類或客戶端的源代碼，違背了“開閉原則”在以下情況下可以使用外觀模式：1）當(dāng)要為一個復(fù)雜子系統(tǒng)提供一個簡單接口時可以使用外觀模式。該接口可以滿足大多數(shù)用戶的需求，而且用戶也可以越過外觀類直接訪問子系統(tǒng)。2）客戶程序與多個子系統(tǒng)之間存在很大的依賴性。引入外觀類將子系統(tǒng)與客戶以及其他子系統(tǒng)解耦，可以提

16、高子系統(tǒng)的獨立性和可移植性。3）在層次化結(jié)構(gòu)中，可以使用外觀模式定義系統(tǒng)中每一層的入口層與層之間不直接產(chǎn)生聯(lián)系，而通過外觀類建立聯(lián)系，降低層之間的耦合度。例如，外觀模式可用于JDBC數(shù)據(jù)庫操作。Session外觀模式則是外觀模式在JavaEE框架中的應(yīng)用。2.4代理模式代理模式（ProxyPattern）可給某一個對象提供一個代理，并由代理對象控制對原對象的引用。代理模式的英文叫做Proxy或Surrogate，它是一種對象結(jié)構(gòu)型模式。代理模式的優(yōu)點如下：1）代理模式能夠協(xié)調(diào)調(diào)用者和被調(diào)用者，在一定程度上降低了系統(tǒng)的耦合度。2）遠(yuǎn)程代理使得客戶端可以訪問在遠(yuǎn)程機器上的對象，遠(yuǎn)程機器可能具有更好

17、的計算性能與處理速度，可以快速響應(yīng)并處理客戶端請求。3）虛擬代理通過使用一個小對象來代表一個大對象，可以減少系統(tǒng)資源的消耗，對系統(tǒng)進(jìn)行優(yōu)化并提高運行速度。4）保護代理可以控制對真實對象的使用權(quán)限。代理模式的缺點如下：1）由于在客戶端和真實主題之間增加了代理對象，因此有些類型的代理模式可能會造成請求的處理速度變慢。2）實現(xiàn)代理模式需要額外的工作，有些代理模式的實現(xiàn)非常復(fù)雜。代理模式的應(yīng)用：1）JavaRMI（RemoteMethodInvocation遠(yuǎn)程方法調(diào)用）。2）EJB、WebService等分布式技術(shù)都是代理模式的應(yīng)用。在EJB中使用了RMI機制,遠(yuǎn)程服務(wù)器中的企業(yè)級Bean在本地有一

18、個樁代理，客戶端通過樁來調(diào)用遠(yuǎn)程對象中定義的方法，而無須直接與遠(yuǎn)程對象交互。在EJB的使用中需要提供一個公共的接口，客戶端針對該接口進(jìn)行編程，無須知道樁以及遠(yuǎn)程EJB的實現(xiàn)細(xì)節(jié)。3)Spring框架中的AOP技術(shù)也是代理模式的應(yīng)用，在SpringAOP中應(yīng)用了動態(tài)代理(DynamicProxy)技術(shù)。行為型模式概述行為型模式(BehavioralPattern)是對在不同的對象之間劃分責(zé)任和算法的抽象化。行為型模式不僅僅關(guān)注類和對象本身，還關(guān)注它們之間的相互作用和職責(zé)劃分。行為型模型包括責(zé)任鏈模式、命令模式、解釋器模式、迭代器模式、中介者模式、備忘錄模式、觀察者模式、狀態(tài)模式、策略模式、模板方

19、法模式、訪問者模式11種模式。下面只介紹比較常用的迭代器模式和觀察者模式。3.1迭代器模式迭代器模式(IteratorPattern):提供一種方法來訪問聚合對象，而不用暴露這個對象的內(nèi)部表示，其別名為游標(biāo)(Cursor)。迭代器模式是一種對象行為型模式。迭代器模式優(yōu)點：1)它支持以不同的方式遍歷一個聚合對象。2)迭代器簡化了聚合類。3)在同一個聚合上可以有多個遍歷。4)在迭代器模式中，增加新的聚合類和迭代器類都很方便，無須修改原有代碼，滿足“開閉原則”的要求。迭代器模式的缺點：1)由于迭代器模式將存儲數(shù)據(jù)和遍歷數(shù)據(jù)的職責(zé)分離，增加新的聚合類需要對應(yīng)增加新的迭代器類，類的個數(shù)成對增加，這在一定

20、程度上增加了系統(tǒng)的復(fù)雜性。在以下情況下可以使用迭代器模式：1)訪問一個聚合對象的內(nèi)容而無須暴露它的內(nèi)部表示。2)需要為聚合對象提供多種遍歷方式。3)為遍歷不同的聚合結(jié)構(gòu)提供一個統(tǒng)一的接口。例如：JDK1.2引入了新的Java聚合框架Collections。3.2觀察者模式觀察者模式(ObserverPattern)定義了對象間的一種一對多依賴關(guān)系，使得每當(dāng)一個對象狀態(tài)發(fā)生改變時，其相關(guān)依賴對象皆得到通知并被自動更新。觀察者模式。又叫做發(fā)布-訂閱(Publish/Subscribe)模式、模型-視圖(Model/View)模式、源-監(jiān)聽器(Source/Listener)模式或從屬者(Dependents)模式。它是一種對象