設計模式在數(shù)據(jù)存儲設計中的應用

張欲蓉，嚴 華

（中國電子科技集團公司51所，上海 201802）

0 引 言

數(shù)據(jù)存儲是各種計算機應用系統(tǒng)的一個重要功能。幾乎所有的計算機應用系統(tǒng)都需要將各種數(shù)據(jù)信息存儲為不同格式的文件。在存儲過程中，數(shù)據(jù)導出與數(shù)據(jù)保存的代碼很容易高度耦合，很難分別對數(shù)據(jù)導出與數(shù)據(jù)保存部分單獨進行修改、擴充與重用。本文所述的數(shù)據(jù)存儲設計，運用bridge和decorator模式，將數(shù)據(jù)導出與數(shù)據(jù)保存解耦，使設計易維護、易擴展、易復用。

1 問題分析

在某個典型的電子對抗領域的應用中，有上級指控命令、信號分選結(jié)果、系統(tǒng)工作日志等數(shù)據(jù)需要存儲，這些數(shù)據(jù)可能需要被存儲為多種格式的文件，如＊.xls、＊.txt、＊.html或＊.mdb等。實現(xiàn)數(shù)據(jù)存儲功能的最常見的2種設計如下：

設計1：設計一個模塊，讓其提供多個接口來滿足需要，這種設計缺點很明顯，降低了代碼的內(nèi)聚性，使之趨于不良耦合，可重用性和可靠性大打折扣。

圖1 設計2的設計類圖

根據(jù)這種設計，假設系統(tǒng)數(shù)據(jù)的種類為M，文件格式的種類為N，則一共要設計M×N個類才能滿足要求。這種設計存在如下問題：（1）每增加一種待導出的數(shù)據(jù)或增加一種文件導出格式，需要增加多個類；（2）如果對待導出數(shù)據(jù)或文件的保存格式進行修改將影響與之相關的多個類；（3）隨著M或N值的增加，最終設計類的個數(shù)會增長為不可控制的龐然大物。

本文所要解決的問題就是提出一種設計，這種設計能減少類的數(shù)量，降低類間的耦合度，保持對象的內(nèi)聚性，易理解，易管理，減少變化帶來的影響，提高重用性［1］。

2 系統(tǒng)設計

軟件設計真正要做的許多內(nèi)容，就是發(fā)現(xiàn)職責并把職責相互分離［2］。將待導出的數(shù)據(jù)視為數(shù)據(jù)源，將數(shù)據(jù)存儲的過程分解為導出和保存2步：導出的職責是按需求過濾、提取、組織數(shù)據(jù)，保存的職責是將組織好的數(shù)據(jù)保存為不同格式文件。經(jīng)分解后2個職責都比較單一，更能適應變化的發(fā)生。數(shù)據(jù)存儲的過程如圖2所示。

圖2 數(shù)據(jù)存儲示意圖

2.1 類的設計

設計類圖見圖3。

圖3 設計類圖

這里設計了2個抽象基類：CExport和CSave。CExport提供數(shù)據(jù)導出的接口，CSave提供數(shù)據(jù)保存的接口。CDB代表數(shù)據(jù)源的抽象，設計時應讓其提供接口，使其他對象能夠獲取數(shù)據(jù)源的數(shù)據(jù)。

CExport派生出CExport Cmd、CExportSignal和CExport Log等子類，CExportCmd子類負責導出上級指控命令，CExportSignal負責導出信號分選結(jié)果，CExport Log負責導出系統(tǒng)工作日志。

CSave派生出 CSaveXls、CSave Txt、CSave Html和CSave Mdb等子類，這些子類分別負責將導出的數(shù)據(jù)保存為xls、txt、html和mdb等格式。

有些數(shù)據(jù)文件可能需要裝飾，例如：數(shù)據(jù)文件需要增加標題或結(jié)尾，于是設計1個抽象類CDecorat－or Export，它是CExport的子類，用于提供統(tǒng)一的裝飾接口。從CDecorator Export派生出2個子類：CDecorator Export Topic和CDecorator Export Tail。CDecorator Export Topic用于增加標題，CDecorator Export Tail用于增加結(jié)尾。如果需要實現(xiàn)其他裝飾功能，從CDecorator Export類派生出相應裝飾作用的類即可。

2.2 實現(xiàn)數(shù)據(jù)導出和數(shù)據(jù)保存的分離

按照圖1的設計，每增加一種待導出數(shù)據(jù)或文件導出格式，就需要增加多個類，最終將導致類的數(shù)量龐大。且一旦有變化發(fā)生，將引起多個類一起變化。究其原因，就是設計類職責過多，耦合過于緊密。緊密耦合導致脆弱的設計，當變化發(fā)生時，設計不能適應這種變化。事實上，完全可以找出哪些是數(shù)據(jù)導出，哪些是數(shù)據(jù)保存，然后進行職責分離，使設計符合單一職責原則［2］。

e.g. A: The dinner is ready. Tim has not made it.Can anybody give him a call?

軟件設計的一個重要原則是依賴倒置原則：高層模塊不應該依賴低層模塊，2個都應該依賴抽象；抽象不應該依賴細節(jié)，細節(jié)應該依賴抽象。針對接口編程，不要對實現(xiàn)編程。相對于實現(xiàn)細節(jié)的多變性，抽象的接口要穩(wěn)定得多。依據(jù)這個原則，設計抽象類CSave和CExport，CExport提供數(shù)據(jù)導出的接口；CSave提供數(shù)據(jù)保存的接口。讓CExport基類維持一個指向CSave類的指針。這樣數(shù)據(jù)導出CExport的各個子類對數(shù)據(jù)保存的依賴關系都終止于抽象類或接口。正是由于這個抽象的依賴關系，以及子類型對父類型的可替換，實現(xiàn)了數(shù)據(jù)導出和數(shù)據(jù)保存的分離。設計類圖見圖4，這種設計是bridge模式的一個應用。

圖4 應用bridge模式實現(xiàn)數(shù)據(jù)導出與數(shù)據(jù)保存的分離

CExport的子類CExportSignal、CExportCmd等和CSave的子類CSaveXls、CSave Html等之間沒有固定的綁定關系，可以在程序運行過程中根據(jù)需要選擇或切換。

下面以將信號分選結(jié)果導出保存為Txt和Html為例進行說明：

／／對數(shù)據(jù)保存的依賴終止于抽象類CSave，可傳入指向CSave的子類的指針，將數(shù)據(jù)保存為不同格式文件。

實現(xiàn)數(shù)據(jù)導出與數(shù)據(jù)保存功能的客戶代碼如下：

／／傳入指向CSave Txt類的指針，實現(xiàn)子類對父類的替換，將信號分選結(jié)果導出保存為txt文件。

m＿p Export－＞Export（m＿pSave Txt）；

／／傳入指向CSave Html類的指針，實現(xiàn)子類對父類的替換，將信號分選結(jié)果導出保存為html文件，不需要對CExportSignal作修改。

m＿pExport－＞Export（m＿pSave Html）；

采用bridge模式的核心意圖，就是將數(shù)據(jù)保存獨立出來，減少與數(shù)據(jù)導出的耦合，讓它與數(shù)據(jù)導出各自獨立地變化，并且該變化對其他部分不會產(chǎn)生影響。

CExport的各個子類只負責按需求過濾、提取、組織數(shù)據(jù)，將保存功能分配給了CSave的各個子類，但是它們能夠共同協(xié)作并提供某種良好界定的行為［3］，因此它們具有高內(nèi)聚的性質(zhì)。每增加一種待導出數(shù)據(jù)，只需要設計一個從CExport派生的子類即可，其他所有的類均不需要任何改變。同樣，每增加一種文件導出格式，只需要增加一個從CSave派生出的子類即可，其他所有類也不需要改變。職責的合理分配與依賴倒置原則的應用，降低了CExport的子類和CSave的子類之間的耦合性，保持了對象的內(nèi)聚性。

CSave Txt、CSave Html、CSaveXls及 CSaveDoc等承擔保存文件職責的類經(jīng)過測試成熟后，便可被其他項目所復用。

2.3 數(shù)據(jù)導出功能的動態(tài)增加

導出日志時，有時需要加上導出日期、日志名稱等信息，或是添加在標題處，或是添加在結(jié)尾處，有時也可能并不需要增加任何裝飾。即裝飾功能是動態(tài)增加的。如何實現(xiàn)這個動態(tài)裝飾功能呢？常見的方法是在數(shù)據(jù)導出類中增加接口。但是這樣就必須修改各個數(shù)據(jù)導出類的接口，增加新的邏輯，導致原有類的復雜度增加，客戶代碼也需要適應這個新的邏輯和接口，一起作修改。當每次增加新的裝飾功能時，修改又會再次發(fā)生在同樣的地方。在設計中應用了decorator模式來隔離這些變化，使變化產(chǎn)生的影響降到最低。

軟件設計應遵循的另一個原則是：開放－封閉原則，就是說軟件實體（類、模塊、函數(shù)等等）應該可以擴展，但是不可修改［2］。即對于擴展是開放的，對于更改是封閉的。但是無論模塊設計得多么“封閉”，都會存在一些無法對之封閉的變化。既然不可能完全封閉，就創(chuàng)建抽象來隔離變化，即找出變化并封裝變化［4］。這里的變化就是動態(tài)增加的裝飾功能。設計的出發(fā)點就是讓CExport類及其子類無需知道裝飾功能的存在，即不對CExport類及其子類作任何修改，保證它們封閉性的同時，提供擴展的開放性。設計類圖見圖5，這種設計是decorator模式的一個應用。

圖5 應用decorator模式實現(xiàn)數(shù)據(jù)導出的動態(tài)增加

設計CDecorator Export類，它是用于裝飾的抽象基類，它還是CExport的子類，與被裝飾的CExport及其子類具有相同的接口。它同時維持一個指向CExport對象的指針，并改寫了從CExport繼承來的Export接口，改寫的示例代碼如下。這為在不改變CExport對象的情況下給CExport對象增加職責提供了基礎。

將CExport對象看作一個核，CDecorator Export對象看作它的外殼，通過套上外殼可以改變核的行為。子類CDecorator Export Topic和CDecorator Export Tail從CDecorator Export派生，將它們實例化后的對象就是核的外殼。它們提供用于裝飾的接口，給CExport對象添加新的職責，一個負責增加標題，一個負責增加結(jié)尾。它們均改寫了從CDecorator Export繼承過來的Export接口，實現(xiàn)裝飾功能。示例代碼如下：

如果需要實現(xiàn)其他裝飾功能，只需增加一個從CDecorator Export派生出來的裝飾類即可，原有的實現(xiàn)數(shù)據(jù)導出與數(shù)據(jù)保存功能的類不需要作任何改動。對于客戶代碼來說，通過與2.1中示例代碼的比較可知，只有實例化CExport類為對象這一個地方有改動，由于裝飾類是CExport的子類，它們具有相同接口，客戶代碼的其余地方均不需要改動。

3 其他

為了增加靈活性和封裝變化，本文在設計中選擇了細粒度的類，每個類都有比較明晰、單一的職責。使用這些細粒度類提供了更為靈活的策略，也提供了更多的可復用性。

在應用中有一點要特別注意，由于裝飾對象的接口與它所裝飾的CExport對象的接口是一致的，保持CExport類的簡單性很重要，否則會使裝飾類擁有一些它們并不需要的功能而難以使用，也使系統(tǒng)付出不必要的代價。設計時，CExport類應集中于定義接口，盡量少地維護數(shù)據(jù)，對數(shù)據(jù)的表示和維護應延遲到其子類中。當CExport類很龐大時，需要考慮使用別的方法來動態(tài)增加裝飾功能。

4 結(jié)束語

設計模式的使用有效地提高了設計的質(zhì)量，使整個設計具有清晰的結(jié)構(gòu)、良好的擴展性和易復用性。本文提出的數(shù)據(jù)存儲設計已成功運用于多個項目，對于縮短項目開發(fā)周期具有積極的意義。

［1］Craig Larman.Applying UML and Parrerns［M］.北京：機械工業(yè)出版社，2006.

［2］Martin Robert C.敏捷軟件開發(fā)：原則、模式與實踐［M］.北京：清華大學出版社，2003.

［3］Booch.Object Solutions：Managing The Object－Oriented Project［M］.New York：Addision－Wesley，1996.

［4］Alan Shalloway，Trott James R.Design Patterns Explained：A New Perspective on Object－oriented Design［M］.徐言聲譯.北京：人民郵電出版社，2006.

［5］Erich G，Richard H，Ralph J，et al.Design Patterns：Elements of Reusable Object－oriented Software［M］.北京：機械工業(yè)出版社，2005.