基于軟件開(kāi)發(fā)下外觀(guān)模式的改進(jìn)研究論文
外觀(guān)模式是使用頻率較高的軟件設計模式之一。針對標準外觀(guān)模式所存在的問(wèn)題，本文提出了兩種外觀(guān)模式改進(jìn)方案并結合實(shí)例進(jìn)行研究。通過(guò)引入抽象外觀(guān)類(lèi)，讓系統具有良好的可擴展性，滿(mǎn)足開(kāi)閉原則;通過(guò)對外觀(guān)類(lèi)實(shí)施單例化，可以確保外觀(guān)對象的唯一性，節約系統資源。
1 引言
設計模式在軟件開(kāi)發(fā)中應用日益廣泛，它們是前人經(jīng)驗的總結與積累，每一種模式均是在多個(gè)軟件項目中被反復使用、被多數人知曉，且經(jīng)過(guò)規范的分類(lèi)編目和整理的面向對象設計經(jīng)驗的總結。
外觀(guān)模式是使用頻率較高的軟件設計模式之一，在軟件開(kāi)發(fā)中應用非常廣泛。根據單一職責原則，將一個(gè)大的軟件模塊(或子系統)進(jìn)行分解可以降低整個(gè)系統的復雜性，提高單個(gè)模塊(或子系統)的'獨立性和可復用性。通過(guò)引入外觀(guān)角色，可以降低客戶(hù)類(lèi)與子系統類(lèi)之間的耦合度，使之相互依賴(lài)關(guān)系降至最小，從而降低原有系統的復雜度。在沒(méi)有外觀(guān)角色的系統中，客戶(hù)類(lèi)需要與多個(gè)子系統類(lèi)進(jìn)行交互，系統耦合度較高;在引入外觀(guān)角色之后，客戶(hù)類(lèi)只需要與外觀(guān)類(lèi)交互，再通過(guò)外觀(guān)類(lèi)間接調用子系統類(lèi)，在外觀(guān)類(lèi)中封裝了與子系統之間的復雜交互關(guān)系，從而降低系統的耦合度。
但是，在標準的外觀(guān)模式中存在兩個(gè)問(wèn)題：首先，標準外觀(guān)模式?jīng)]有提供抽象層，在增加、更換或者刪除子系統類(lèi)時(shí)需要修改客戶(hù)類(lèi)或者外觀(guān)類(lèi)的源代碼，違背了開(kāi)閉原則;其次，外觀(guān)類(lèi)維持了對多個(gè)子系統類(lèi)的引用，在系統運行時(shí)，外觀(guān)對象勢必會(huì )占用較多的系統資源，需要對外觀(guān)對象的數量進(jìn)行限制。
2 外觀(guān)模式的改進(jìn)方案
針對標準外觀(guān)模式存在的問(wèn)題和缺陷，本文提出了相應的改進(jìn)方案，包括引入抽象外觀(guān)類(lèi)以及對外觀(guān)類(lèi)實(shí)施單例化。
2.1 抽象外觀(guān)類(lèi)的引入
為了讓外觀(guān)模式能夠符合開(kāi)閉原則，引入抽象外觀(guān)類(lèi)來(lái)對外觀(guān)模式進(jìn)行抽象化改進(jìn)�？蛻�(hù)端針對抽象外觀(guān)類(lèi)進(jìn)行編程，將所有的具體外觀(guān)類(lèi)作為抽象外觀(guān)類(lèi)的子類(lèi)，如果需要更改業(yè)務(wù)需求，無(wú)須修改原有外觀(guān)類(lèi)，只需要增加一個(gè)新的具體外觀(guān)類(lèi)即可，由新的外觀(guān)類(lèi)來(lái)關(guān)聯(lián)新的業(yè)務(wù)需求。通過(guò)使用配置文件，可以達到不修改任何源代碼即可置換外觀(guān)類(lèi)的目的，如圖1所示。
2.2 外觀(guān)類(lèi)的單例化
在大多數情況下，為了節約系統資源，程序在運行時(shí)只需創(chuàng )建某個(gè)外觀(guān)類(lèi)的唯一實(shí)例。因此，可以將外觀(guān)模式與單例模式聯(lián)用，對外觀(guān)類(lèi)實(shí)施單例化，確保系統中只存在唯一一個(gè)外觀(guān)對象并提供唯一的訪(fǎng)問(wèn)入口，可以降低系統資源的消耗。單例化后的外觀(guān)類(lèi)的結構如圖2所示。
在圖2中，外觀(guān)類(lèi)Facade被設計為單例類(lèi)，在其中定義了一個(gè)靜態(tài)的Facade類(lèi)型的成員變量instance，其構造函數為私有的(private)，并通過(guò)一個(gè)靜態(tài)的公有工廠(chǎng)方法getInstance()返回自己的唯一實(shí)例。
3 實(shí)例研究
下面通過(guò)一個(gè)實(shí)例來(lái)說(shuō)明如何在實(shí)際項目中使用改進(jìn)后的外觀(guān)模式。
在某使用外觀(guān)模式的文件加密模塊的初始設計方案中，FileReader類(lèi)用于讀取待加密的源文件、FileWriter類(lèi)用于保存加密之后的文件、Cipher類(lèi)用于實(shí)現數據的加密，EncryptFacade是一個(gè)加密外觀(guān)類(lèi)，它通過(guò)調用三個(gè)業(yè)務(wù)類(lèi)中的方法實(shí)現文件讀取、加密和保存的完整流程。
3.1 抽象化改進(jìn)
如果需要將原系統中的加密類(lèi)Cipher改為NewCipher，勢必會(huì )導致外觀(guān)類(lèi)EncryptFacade源代碼發(fā)生修改，違背開(kāi)閉原則。通過(guò)引入抽象外觀(guān)類(lèi)，重構后的系統設計方案如圖3所示，在圖3中使用了基于衍型的模式標注方法SBPN (Stereotype Based Pattern Notation)來(lái)對結構圖中的設計模式信息進(jìn)行標注。
在圖3中，客戶(hù)類(lèi)Client針對抽象外觀(guān)類(lèi)AbstractEncryptFacade進(jìn)行編程，可將具體外觀(guān)類(lèi)類(lèi)名存儲在XML等格式的配置文件中，更換具體外觀(guān)類(lèi)時(shí)只需修改配置文件，無(wú)須修改源代碼，符合開(kāi)閉原則。
3.2 單例化改進(jìn)
為了節省系統資源，可以將EncryptFacade設計為單例類(lèi)，改進(jìn)之后的結構如圖4所示。
通過(guò)對外觀(guān)類(lèi)實(shí)施單例化，可以確保系統中有且僅有一個(gè)EncryptFacade類(lèi)的實(shí)例，避免生成多個(gè)EncryptFacade對象，節約系統資源。
4 結束語(yǔ)
外觀(guān)模式是一種使用頻率非常高的設計模式，在軟件開(kāi)發(fā)中應用廣泛。針對標準外觀(guān)模式存在的不足，本文提出了兩種外觀(guān)模式的改進(jìn)方案：第一種方案通過(guò)引入抽象外觀(guān)類(lèi)，使得系統在增加、刪除或者更換子系統類(lèi)時(shí)無(wú)須修改已有類(lèi)的源代碼，可以對抽象外觀(guān)類(lèi)進(jìn)行擴展來(lái)適應設計方案的改變，讓系統滿(mǎn)足開(kāi)閉原則;第二種方案通過(guò)對外觀(guān)類(lèi)單例化，將外觀(guān)模式與單例模式聯(lián)用，確保在系統中只存在外觀(guān)類(lèi)的唯一實(shí)例，節約系統資源。通過(guò)上述改進(jìn)，可以提高外觀(guān)模式的適用性和有效性。
【基于軟件開(kāi)發(fā)下外觀(guān)模式的改進(jìn)研究論文】相關(guān)文章：
基于土工實(shí)驗教學(xué)模式的研究論文01-27
基于網(wǎng)絡(luò )包裝技術(shù)下軟件開(kāi)發(fā)的遠程監控系統研究論文10-31
基于A(yíng)ndroid平臺軟件開(kāi)發(fā)技術(shù)研究論文11-07
基于Maven的輕量級Java軟件開(kāi)發(fā)研究論文11-02
基于CMMI的軟件開(kāi)發(fā)模型應用研究論文11-04
基于權力話(huà)語(yǔ)理論下的翻譯策略研究論文11-01
高職下慕課項目教學(xué)模式研究論文07-30