，

(1.長江水利委員會水文局，武漢 430010；2. 深圳市華威世紀(jì)科技股份有限公司，廣東 深圳 518000)

1 模式起源

設(shè)計模式(Design Pattern)是一套被反復(fù)使用、為多數(shù)人知曉、并經(jīng)分類編目，關(guān)于代碼設(shè)計經(jīng)驗的系統(tǒng)總結(jié)。使用設(shè)計模式是為了增強(qiáng)代碼的可重用性，提高開發(fā)效率，讓代碼更容易理解，保證軟件可靠性。

模式起源于建筑業(yè)而非軟件業(yè)，最初由原美國加利佛尼亞大學(xué)環(huán)境結(jié)構(gòu)中心研究所所長，被稱為“模式之父”的Christopher Alexander博士提出。他在其專著《A Pattern Language: Towns, Buildings, Construction》中提出了“模式”的概念，應(yīng)用于建筑設(shè)計。他所指的模式的內(nèi)涵為：“模式是在特定環(huán)境下人們解決某類重復(fù)出現(xiàn)問題的一套成功或有效的解決方案”。

20世紀(jì)80年代以來，軟件工程界也逐漸關(guān)注Christopher Alexander等在住宅、公共建筑與城市規(guī)劃領(lǐng)域的重大突破。從1995年至今，設(shè)計模式在軟件開發(fā)方面得到了越來越多的企業(yè)和高校的關(guān)注與重視，如Sun公司的Java SE/Java EE平臺和Microsoft的.NET平臺中均應(yīng)用了大量的設(shè)計模式。嚴(yán)格來說，只要支持面向?qū)ο缶幊?OOP)的程序設(shè)計語言均可使用設(shè)計模式進(jìn)行編程，如C++、Java、C#、Objective-C、VB.net、Smalltalk、Ruby等。1994年，Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides出版了《Design Patterns》著作，在該書中歸納了23種軟件開發(fā)中使用頻率較高的設(shè)計模式。

2 模式分類

面向?qū)ο缶幊淌谴罅垦芯砍晒奶釤捙c匯總，遵循這些原則設(shè)計的程序往往具有較高的復(fù)用性、較強(qiáng)的靈活性。而設(shè)計模式就是遵循上述面向?qū)ο笤O(shè)計原則，升華總結(jié)出的經(jīng)驗和編程方法。

2.1 面向?qū)ο蠡驹瓌t

面向?qū)ο缶幊?Object Oriented Programming，簡稱OOP)是一種計算機(jī)編程架構(gòu)。傳統(tǒng)的面向過程編程是按照特定的業(yè)務(wù)邏輯，分步執(zhí)行相應(yīng)的代碼，重用性、靈活性及擴(kuò)展性較差；而OOP則將所有業(yè)務(wù)邏輯封裝為對象，每個對象都具有屬性、方法，對象之間交互通過消息進(jìn)行通信。OOP模式可簡化編程步驟，編制的程序具有較高的重用性及靈活性。面向?qū)ο笤O(shè)計原則是OOP編程的核心，面向?qū)ο蟮脑O(shè)計原則(SOLID原則)主要有五方面：

(1)單一職責(zé)原則(Single Responsibility Principle)。該原則強(qiáng)調(diào)一個對象應(yīng)該只包含單一的職責(zé)，并且該職責(zé)被完整地封裝在一個類中。對于具有多種功能的邏輯業(yè)務(wù)應(yīng)分離成多個對象(類)。

(2)開放封閉原則(Open Closed principle)。這一原則是保持OOP設(shè)計靈活性、擴(kuò)展性的核心。該原則強(qiáng)調(diào)“軟件實體應(yīng)該是可以擴(kuò)展的，但是不可修改”。我們在增加系統(tǒng)功能的時候，不應(yīng)修改現(xiàn)有代碼，應(yīng)增加新代碼，以保持已有系統(tǒng)的穩(wěn)定性。

(3)里氏替換原則(Liskov Substitution Principle)。該原則主張使用“抽象(Abstraction)”和“多態(tài)(Polymorphism)”將設(shè)計中的靜態(tài)結(jié)構(gòu)改為動態(tài)結(jié)構(gòu)，維持設(shè)計的封閉性?！俺橄蟆笔钦Z言提供的功能。“多態(tài)”由繼承語義實現(xiàn)。

(4)依賴倒置原則(Dependency Inversion Principle)。該原則主張程序要依賴于抽象接口，不要依賴于具體實現(xiàn)。簡單的說就是要求對抽象進(jìn)行編程，不要對實現(xiàn)進(jìn)行編程，這樣就降低了客戶與實現(xiàn)模塊間的耦合。

(5)接口隔離原則(Interface-Segregation Principle)。該原則是單一職責(zé)原則用于接口設(shè)計的自然結(jié)果。一個接口中包括的功能是有限的，不同的功能可封裝在不同的接口中。

2.2 設(shè)計模式分類

根據(jù)設(shè)計模式的用途分類，設(shè)計模式可分為創(chuàng)建型(Creational)、結(jié)構(gòu)型(Structural)及行為型(Behavioral)3類。其中，創(chuàng)建型模式主要用于創(chuàng)建對象，結(jié)構(gòu)型模式主要用于處理類或?qū)ο蟮慕M合，行為型模式主要用于描述類或?qū)ο笕绾谓换ズ驮鯓臃峙渎氊?zé)。具體分類見表1。

表1 設(shè)計模式分類表

3 典型應(yīng)用

限于篇幅，本文以觀察者模式為研究典型，以水文信息推送APP框架設(shè)計為對象，具體說明設(shè)計模式在水文信息化軟件設(shè)計中的應(yīng)用。

3.1 觀察者模式基本原理

觀察者模式是一種行為型模式，該模式定義了對象之間一對多的依賴關(guān)系，讓一個對象的改變能夠影響其它對象。發(fā)生改變的對象稱為觀察目標(biāo)，被通知的對象稱為觀察者。一個觀察目標(biāo)可以對應(yīng)多個觀察者。觀察者模式較好地實踐了單一職責(zé)原則、開閉原則、依賴倒置原則及接口隔離原則，因此在編程實踐中被大量使用，著名的微軟.Net平臺的事件機(jī)制就采用了觀察者模式的設(shè)計思路。其UML圖如圖1。從圖可知，Subject和Observer均是接口，而ConcreteSubject和ConcreteObserver才是具體的實現(xiàn)類。

圖1觀察者模式UML圖

3.2 水文信息推送APP設(shè)計

(1)問題的提出

水文信息是為防汛減災(zāi)、水資源管理及國民經(jīng)濟(jì)建設(shè)各領(lǐng)域服務(wù)的基礎(chǔ)支撐信息。2015年3月5日，李克強(qiáng)總理在十二屆全國人大三次會議政府工作報告中首次提出了“互聯(lián)網(wǎng)+”行動計劃。通俗的說，“互聯(lián)網(wǎng)+”就是“互聯(lián)網(wǎng)+各個傳統(tǒng)行業(yè)”，但這并不是簡單的兩者相加，而是利用信息通信技術(shù)以及互聯(lián)網(wǎng)平臺，讓互聯(lián)網(wǎng)與傳統(tǒng)行業(yè)進(jìn)行深度融合，創(chuàng)造新的發(fā)展生態(tài)。

在“互聯(lián)網(wǎng)+”的技術(shù)背景下，水文監(jiān)測部門采用移動互聯(lián)技術(shù)，開發(fā)相應(yīng)的APP軟件，將原來采集的水文信息，由用戶主動請求獲取的模式，升級為由數(shù)據(jù)中心主動向用戶終端推送的模式。這一轉(zhuǎn)變一方面可提高水文監(jiān)測部門的服務(wù)水平及時效性，另一方面也提升了公眾對水文監(jiān)測部門的關(guān)注度。

水文監(jiān)測數(shù)據(jù)的采集報送系統(tǒng)架構(gòu)見圖2。系統(tǒng)由監(jiān)測端、傳輸網(wǎng)絡(luò)、數(shù)據(jù)中心及用戶終端等幾個部分組成。監(jiān)測端完成水位、雨量、流速等信息的采集；通過傳輸網(wǎng)絡(luò)將實時數(shù)據(jù)傳輸至數(shù)據(jù)中心；數(shù)據(jù)中心通過數(shù)據(jù)清洗、數(shù)據(jù)在線整理整編后完成信息推算；用戶終端則是水文信息的最終用戶，可通過計算機(jī)、移動通信終端等設(shè)備進(jìn)行數(shù)據(jù)的在線訪問。

圖2水文監(jiān)測信息推送架構(gòu)圖

隨著通信技術(shù)及電子信息技術(shù)的迅猛發(fā)展，用戶訪問數(shù)據(jù)終端出現(xiàn)了多元化，有手機(jī)、臺式電腦、筆記本電腦等。對于不同終端，其采用的操作系統(tǒng)、顯示界面等均有很大的差異。以操作系統(tǒng)為例而言，計算機(jī)終端采用Windows、Linux等，手機(jī)等移動終端采用Android(谷歌)、Linux(蘋果)、Windows Mobile(微軟)等。而電子信息及軟件技術(shù)發(fā)展是十分迅速的，今后一定會出現(xiàn)新的性能優(yōu)良的操作系統(tǒng)。因此，如何設(shè)計一個具有高度靈活性、可擴(kuò)展性信息推送APP，則是本項目成功實施的關(guān)鍵因素之一。

(2)傳統(tǒng)設(shè)計方案

由于不同操作系統(tǒng)的采用的數(shù)據(jù)連接方式、圖形顯示API均有較大的差別。因此需將不同操作系統(tǒng)所需執(zhí)行的操作封裝為單獨的函數(shù)，見圖3。在信息推送APP業(yè)務(wù)主邏輯中必然會存在多組判別的條件選擇語句。這樣做的弊端就是，當(dāng)新的操作系統(tǒng)出現(xiàn)時，一方面需為新操作系統(tǒng)編寫專用代碼，另一方面還需修改APP的主邏輯代碼(添加另一組條件判斷語句)，違反了面向?qū)ο笤O(shè)計原則的“開閉”原則，架構(gòu)的靈活性不好，擴(kuò)展性也較差，給系統(tǒng)的維護(hù)與升級造成較大的困難。

圖3信息推送APP架構(gòu)設(shè)計圖(傳統(tǒng)設(shè)計方案)

(3)優(yōu)化設(shè)計方案

從上述設(shè)計方案可見，信息推送APP架構(gòu)設(shè)計中的“變化點”是接收終端操作系統(tǒng)的變換。根據(jù)面向?qū)ο蟪绦蛟O(shè)計原則，我們應(yīng)采用設(shè)計模式封裝“變化點”。經(jīng)分析，觀察者模式是解決此類問題的最佳方案。

在本研究中，觀察目標(biāo)為HydroData對象，它實現(xiàn)了Subject接口。觀察者為各類終端對象，如基于Windows系統(tǒng)的WindowsTerminal對象，基于IOS系統(tǒng)的IOSTerminal對象和基于Android系統(tǒng)的AndroidTerminal對象，它們都實現(xiàn)了Observer接口。為了對各自接收到的水位、雨量及流量信息進(jìn)行顯示，分別還實現(xiàn)了ShowInformation接口。系統(tǒng)設(shè)計見圖4。

Subject接口中提供了NotifyObservers()、RegisterObserver()及RemoveObserver()等3個方法。RegisterObserver()方法用于向觀測目標(biāo)中添加觀測者對象，實現(xiàn)消息的訂閱；RemoveObserver()方法用于從觀測目標(biāo)中移除觀測者對象，取消消息的訂閱；NotifyObservers()方法用于向所用觀測者對象發(fā)布消息，推送即時信息。

圖4基于觀察者模式的APP架構(gòu)設(shè)計圖

Observer接口中提供了Update()方法，用于更新觀測目標(biāo)發(fā)來的即時信息，并將其信息存儲在緩存中。根據(jù)接口隔離原則，還提供了ShowInformation()接口，該接口ShowInfo()方法用于將收到的即時信息，更新相關(guān)的界面。

圖5為HydroData業(yè)務(wù)邏輯偽代碼，實現(xiàn)了觀察目標(biāo)的業(yè)務(wù)主邏輯；圖6為IOSTerminal業(yè)務(wù)邏輯偽代碼，實現(xiàn)了IOS操作系統(tǒng)下信息獲取及更新的業(yè)務(wù)邏輯，其它操作系統(tǒng)的業(yè)務(wù)邏輯與IOS是相似的；圖7為客戶端偽代碼，在這里可以添加觀察者對象，發(fā)布消息。

圖5HydroData業(yè)務(wù)邏輯偽代碼

圖6IOSTerminal業(yè)務(wù)邏輯偽代碼

圖7客戶端偽代碼

使用觀察者模式后，對于新的操作系統(tǒng)，如華為研制的Huawei系統(tǒng)，只需新增HuaweiTerminal對象的業(yè)務(wù)邏輯，實現(xiàn)Observer及ShowInformation接口，其它邏輯不需修改，從而實現(xiàn)了面向?qū)ο蟪绦蛟O(shè)計中的“開閉”原則，增加了程序設(shè)計的靈活性及可擴(kuò)展性。

4 結(jié)論與展望

設(shè)計模式的應(yīng)用是為了符合面向?qū)ο笤O(shè)計原則，最終旨在提高代碼的復(fù)用性和系統(tǒng)的靈活性、可擴(kuò)展性。Erich Gamma、Richard Helm、Ralph Johnson和John Vlissides提出的23種設(shè)計模式是在當(dāng)時(1994年)對過去編碼的經(jīng)驗總結(jié)。隨著技術(shù)的進(jìn)步，現(xiàn)有的設(shè)計模式遠(yuǎn)遠(yuǎn)不止這23種，據(jù)不完全統(tǒng)計，現(xiàn)有各種模式已達(dá)1 000余種。不管模式的種類如何變化、數(shù)量如何增多，其設(shè)計的初衷均是為了充分滿足面向?qū)ο蟮脑O(shè)計原則，減輕程序員編碼的難度，增加系統(tǒng)的靈活性。因此，在水文信息化軟件開發(fā)過程中，應(yīng)充分利用面向?qū)ο蟮脑O(shè)計思想，利用各種優(yōu)秀的設(shè)計模式，編制出高內(nèi)聚、低耦合的應(yīng)用系統(tǒng)。

[1] 江華麗.基于AOP策略模式的實現(xiàn)機(jī)制[J].微型機(jī)與應(yīng)用, 2016(35).

[2] 李瑞雪.設(shè)計模式在軟件設(shè)計中的運用[J].電子技術(shù)與軟件工程, 2016(23).

[3] 劉東生.設(shè)計模式及其在軟件設(shè)計中的應(yīng)用研究[J].數(shù)字技術(shù)與應(yīng)用, 2015(7).

[4] 武光明.設(shè)計模式在全球化軟件開發(fā)中的應(yīng)用[J].計算機(jī)應(yīng)用與軟件, 2014(1).

[5] 劉 偉，胡志剛等.C#設(shè)計模式[M].北京：清華大學(xué)出版社, 2013.

[6] 伽瑪?shù)戎?；李英軍等譯.設(shè)計模式：可復(fù)用面向?qū)ο筌浖幕A(chǔ)[M].北京：機(jī)械工業(yè)出版社, 2015.