Ｏｂｓｅｒｖｅｒ模式與Ｃｏｍｍａｎｄ模式在條碼采集系統(tǒng)中的應用研究

摘要：結合條碼采集系統(tǒng)的設計與開發(fā)，探討了設計模式中的Observer模式與Command模式，結果表明：使用Observer模式進行數據管理，使用Command模式進行功能管理，可以增強系統(tǒng)代碼的重用性、靈活性和模塊化，提高了系統(tǒng)開發(fā)效率。

關鍵詞：設計模式；Observer模式；Command模式

中圖分類號：TP311文獻標識碼：A文章編號：1009-3044(2009)04-1002-02

The Research about Application of Observer Pattern and Command Pattern in Barcodes Collecting System

JIAO Fu-qiang1， MIN Lian-ying1， ZHAO Hui2， PEI Chao-ju1

(1.Computer Department， Wuhan University of Technology， Wuhan 430063， China ;2 Basic Department， Henan Business College，Zhengzhou 450044， China)

Abstract: The discussion of Observer Pattern and Command Pattern based on the designing and development of the Barcodes Collecting System come to the conclusion that the using of Observer Pattern and Command Pattern in the Barcodes Collecting System enhanced the reusability， flexibility and modularity of the codes of the Barcodes Collecting System and improve the development efficiency of the system.

Key words: design pattern; observer pattern; command pattern

1 引言

近年來，隨著信息技術的飛速發(fā)展，各企業(yè)紛紛組建起自己的信息管理系統(tǒng)。產品入庫與售后服務是企業(yè)生產的重要環(huán)節(jié)，同時也是企業(yè)管理系統(tǒng)數據的第一手資料來源，所以更應該重視其數據的準確性、有效性及全面性。文中將介紹基于SmartArm2200+μcLinux+QT的手持設備上實現的條碼采集系統(tǒng)，本文只討論上層軟件以及實現過程中Observer模式和Command模式的應用。

2 設計模式

設計模式描述了在面向對象軟件設計過程中針對特定問題的簡潔而優(yōu)雅的解決方案。

設計模式最重要的思想是“封裝變化的概念”。一方面，設計的軟件具有一定的靈活性，以適應可能的變化；另一方面，把這種復雜性所帶來的軟件復雜性進行封裝，為外界提供一個簡單而又穩(wěn)定的訪問接口。

3 條碼采集系統(tǒng)簡介

該條碼采集系統(tǒng)主要通過掃描傳感器掃入條碼數據，經過系統(tǒng)的加工，通過通信接口傳入上位機。它的主要功能：采集傳感器轉換后的條碼信息并將其顯示在LCD顯示屏上，用戶通過鍵盤向系統(tǒng)提出自已的要求，條碼采集系統(tǒng)通過處理按鍵消息以及菜單消息以響應用戶提出的要求，實現用戶與系統(tǒng)之間的交互。本系統(tǒng)以條碼信息、地址信息、索引信息，條碼類型的組合為基本操作單位（簡稱條碼記錄）。本系統(tǒng)主要處理三種類型的條碼記錄，它們是：無符加信息的條碼記錄，入庫產品條碼記錄和銷售產品條碼記錄。本系統(tǒng)實現了入庫產品與銷售產品信息采集與處理功能。條碼采集系統(tǒng)共分為五個功能模塊，分別為：

1) 用戶界面顯示模塊：完成條碼信息采集，然后將條碼信息顯示在界面上。負責用戶與系統(tǒng)之間的交互，正確地將信息顯示在添加頁面、刪除頁面、修改頁面，預覽頁面。

2) 業(yè)務邏輯模塊：主要完成對條碼記錄中各個數據單元（條碼信息、地址信息、索引信息等）按照預定好的規(guī)則進行修改、刪除、添加等操作。

3) 數據存儲模塊：將處理過的數據按照預先設定好的格式存儲。

4) 數據通信模塊：以預先制定的通信協(xié)義組織、驗證通信數據；負責該手持設備與外部設備通過串口穩(wěn)定而正確地進行通信。

5) 條碼解析模塊：識別條碼記錄的類型，如果是入庫產品條碼記錄與銷售產品條碼記錄，則根據相應的檢驗規(guī)則判定待檢驗條碼記錄的合法性。如果條碼記錄合法，則按照預先的設定的規(guī)則對條碼進行解析，提取出有效信息，顯示在預覽頁面上。

4 Observer模式、Command模式在條碼采集系統(tǒng)中的應用

4.1 系統(tǒng)設計分析

本系統(tǒng)中存在的兩個問題是：

1) 當發(fā)生業(yè)務邏輯動作，條碼記錄的內容或數量發(fā)生變化，而與條碼記錄的顯示頁面卻不能及時地反映數據的變化。如當新增一條條碼記錄時，由于修改頁面與預覽頁面沒有得到數據變化的消息，因此顯示的數據（條碼記錄數等）便與實際數據不一致了；當我們在刪除頁面刪除最后一條記錄，修改頁面與預覽頁面卻顯示還有一條條碼記錄；當把一條入庫條碼記錄修改為銷售條碼記錄，但由于預覽、刪除頁面沒有得到通知，它們顯示未修時的條碼記錄信息。 這必將給企業(yè)生產上和管理上帶來很大的麻煩，造成不必要的浪費和損失。

2) 我們對三種類型的條碼記錄進行操作，可以用枚舉型值來標識三種類型，如0，1，2分別代表無符加信息條碼記錄、入庫產品條碼記錄和銷售產品條碼記錄，如果我們想讓0代表入庫產品條碼記錄，1代表無符加信息條碼記錄，那么與類型相關的代碼均需要修改；如果我們要新增一種條碼記錄，則要新增類型枚舉定義，新類型賦值，新類型判別相關代碼；這樣命令的發(fā)出者與執(zhí)行者緊密耦合，進行修改時工作量大，容易出錯。

為解決以上兩個問題，本文只討論Observer模式、Command模式在用戶界面顯示模塊以及業(yè)務邏輯模塊中的應用，其結構圖如圖1所示。

條碼采集系統(tǒng)使用MVC（Model-View-Controller)整體框架。模型（Model）（Data類）用于表示數據和業(yè)務規(guī)則，模型返回的數據是與數據格式無關的，一個模型號能為多個視圖提供數據。視圖（View）（Page類）是用戶看到并與之交互的界面?？刂破鳎–ontroller）

（MyManager類）接受用戶的輸入并調用視圖去完成用戶的需求。當用戶按鍵時，控制器本身不輸出任何東西和做任何處理。它只是接收請求并決定調用哪個模型去處理請求，然后確定用哪個視圖來顯示模型處理返回的數據，負責一部分職能。如果某一部分的需求發(fā)生變化，只需改動相應的部分即可?？墒瓜到y(tǒng)開發(fā)工作更加系統(tǒng)化、模塊化，更能體現面向對象的設計思想，提高了系統(tǒng)的可擴展性。

4.2 Observer模式在顯示模塊的應用

Observer模式的意圖是：“定義對象間的一種一對多依賴關系，當一個對象狀態(tài)發(fā)生改變時，所有依賴于它的對象都得到通知并被自動更新”[2]。

使用Observer模式，可以使本系統(tǒng)在用戶界面和業(yè)務邏輯之間劃分清晰的界限。Data即為Subject，Page即為Observer，當主體對象中發(fā)生更改時，觀察者就會觀察這種更改，并相應地更新其顯示。

下面以AddPage為例子，詳細描述了Observer模式在本系統(tǒng)的應用過程。在這個過程中涉及到的類以及類的主要方法如圖2所示。

主體（ConcreteData）維護一個類型為vector的容器變量，用來存放觀察本主體的觀察者，由于容器本身的性質，使得主體可以支持多個觀察者，這使得主體有可能向多個觀察者通知所發(fā)生的狀態(tài)變化，而不是一個。首先觀察者AddPage調用Register方法，將指向ConcreteData的指針作為參數傳遞，主體將此觀察者存儲在容器變量中，以便在將來某個時間狀態(tài)發(fā)生變化是通知觀察者。當條碼記錄的某一項發(fā)生變化（被修改、刪除等），主體通過GetPage方法來檢索所有的觀察者，主體然后枚舉被檢索的觀察者，并調用NotifyPage方法以通知觀察者所發(fā)生的狀態(tài)變化。當觀察者（AddPage）不再需要觀察主體（ConcreteData）時，觀察者（AddPage）調用UnRegister方法以結束觀察過程。

另處，觀察者與主體均采用面向接口的技術實現，利用這些接口有助于減少觀察者和主體這間的耦合關系，使得觀察者和主體都可以獨立地發(fā)生結構上的變化，而使另一方受到較小的影響。這種方法將接口編程模型的優(yōu)點擴展到本系統(tǒng)中。

4.3 Command模式在業(yè)務邏輯模塊的應用

Command模式的意圖是：將一個請求封裝為一個對象，從而使你可用不同的請求對客戶進行參數化；對請求排隊或記錄請求日志，以及支持可撤消的操作[3]。每一個命令都是一個操作：請求的一方發(fā)出請求要求執(zhí)行一個操作；接收的一方收到請求，并執(zhí)行操作。命令模式允許請求的一方和接收的一方獨立開來，使得請求的一方不必知道接收請求的一方的接口，更不必知道請求是怎么被接收，以及操作是否被執(zhí)行、何時被執(zhí)行，以及是怎么被執(zhí)行的。

條碼采集系統(tǒng)的核心問題是對條碼信息進行處理，系統(tǒng)中有修改、添加、刪除等數據操作，在業(yè)務邏輯模塊使用Command模式使該系統(tǒng)層次更加分明，職責更加明確，結構更加清晰，系統(tǒng)更加容易擴展。

下面以AddCom為例子，詳細描述了Command模式在本系統(tǒng)的應用過程。在這個過程中涉及到的類以及類的主要方法如圖3所示。

請求者（MyManger）維護一個類型為vector的容器變量，用來存放多個請求對象，當用戶要進行操作時，使用GetCommand方法得到命令對象（AddCom），然后調用Execute方法。其中Command類作為接口，只有一個統(tǒng)一的方法，不同的命令類對應接口不同的實現。AddCom類即為添加操作對應的類，它是Command類的一個具體的實現，AddCom通過委托實現具體的添加操作。這樣，MyManager對于它實際調用的對象AddAction是一無所知的，它只知道當代表添加的鍵按下的時候就調用AddCom的Execute()方法；AddAction當然更不知道誰在調用它。通過這種方式，我們實現了調用者（MyManager）和接收者（AddCom）的解耦。如果將來我們需要對這個MyManager進行擴展，只需要再添加一個實現了Command接口的對象就可以了，對于MyManager無需做任何修改。然后通過AddCommand方法向請求者所維護的容器變量中添入新的命令對象指針，實現用戶添加操作的意圖。在請求者（MyManager）與接收者（AddAction）之間增加一個中間層，隔離了請求者與接收者，降低了請求者與接收者之間的耦合度，增強代碼的健壯性、可維護性和復用性。

5 結束語

實踐證明，將Observer模式和Command模式引入到條碼采集系統(tǒng)的設計和實現中，有效提高了軟件開發(fā)的效率，保證了代碼的可重用性和系統(tǒng)的可擴展性，可以滿足不斷增長的不同用戶的不同業(yè)務需求。設計模式使軟件設計人員能夠快速地根據問題找到對應的解決方案。借鑒他人的成功經驗，既可以將其應用于整體的軟件架構設計，也可應用與軟件中某一部分的微體系結構設計。對設計模式的理解和運用需要我們在實踐中不斷地摸索和總結。

參考文獻：

[1] Gamma E，Helm R，Champaign U，et al.設計模式——可復用面向對象軟件的基礎[M].李英軍，譯.北京:機械工業(yè)出版社，2005.

[2] Parikh G.Software Support， Management， and Evolution in the Coming Decade and Beyond Opportunities Challenges[C]//Proceedings of the 21st IEEE International Conference on Software Maintenance，Washington， D. C. 2005.

[3] 劉海巖，鎖志海，呂青，等.設計模式及其在軟件設計中的應用研究[J].西安交通大學學報，2005，39(10):1043-1047.