《BREW進階與精通——3G移動增值業務的營運、定制與開發》連載之13---BREW精要之COM 模型

版權聲明：本文為半吊子子全棧工匠（wireless_com，同公衆号)原創文章，未經允許不得轉載。 https://blog.csdn.net/wireless_com/article/details/4358801

COM是Component Object Model （元件對象模型）的縮寫。BREW基本上遵從COM這一元件構架的。元件架構的一個優點就是應用可以随時間的流逝而發展進化，除此之外，使用元件還有一些可以使對以有應用的更新更加友善和靈活的優點，如應用的定制，元件庫以及分布式元件等。

BREW的COM屬性

COM原本是微軟公司為了計算機工業的軟體生産更加符合人類的行為方式開發的一種軟體開發技術。在COM構架下，人們可以開發出各種各樣的功能專一的元件，然後将它們按照需要組合起來，構成複雜的應用系統。由此帶來的好處是多方面的：可以将系統中的元件用新的替換掉，以便随時進行系統的更新和定制；可以在多個應用系統中重複利用同一個元件；可以友善的将應用系統擴充到網絡環境下；COM與語言，平台無關的特性使所有的程式員均可充分發揮自己的才智與專長編寫元件子產品等等。

BREW

SDK中所提供的服務實際上是一些小的二進制可執行程式形成的元件，它們可以給應用程式、作業系統以及其他元件提供服務。開發自定義的BREW元件（例如，BREW 擴充類）就好像是開發動态的、面向對象的API。多個BREW對象可以連接配接起來形成應用程式或元件系統。并且元件可以在運作時刻，在不被重新連結或編譯應用程式的情況下被卸下或替換掉。

COM實際上象結構化程式設計及面向對象程式設計方法那樣，也是一種程式設計方法。使用元件的種種優點直接來源于可以将它們動态的插入或卸出應用。為了實作這種功能，所有的元件必須滿足兩個條件：第一，元件必須動态連結；第二，它們必須隐藏（或封裝）其内部實作細節。動态連結對于元件而言是一個至關重要的要求，而消息隐藏則是動态連結的一個必要條件。

總的來說，BREW可以在運作時刻同其他元件連接配接起來構成某個應用程式，可以動态的插入或卸出應用，是動态連結的。BREW隐藏（封裝）其内部實作細節，基于BREW的應用以二進制的形式釋出，可以在不妨礙已有使用者的情況下被更新。BREW的自定義擴充按照一種标準的方式來宣布它們的存在。

BREW中的接口

COM的對象之間通過接口進行互動。接口是包含了一組函數的資料結構，通過這組資料結構，代碼可以調用元件對象的功能。接口定義了一組成員函數，這組成員函數是元件對象暴露給使用者的所有可用資訊，客戶可以利用這些資訊取得元件提供的服務。與COM使用GUID作為接口的唯一辨別類似，BREW使用稱之為ClassID的一個4位元組無符号整數作為唯一辨別。

BREW提供了一組固定的接口，哪怕以後實作的方式出現了變化，隻要應用程式群組件程式之間的接口不變，就不需要任何改變。從技術上講，接口是包含了一組函數的資料結構，通過這組資料結構，使用者可以調用元件的功能。同樣與COM類似，BREW使用基于接口對象的引用計數來控制接口的生存期，并且為多個程式之間共享統一接口對象提供了有效的控制手段。一般來說，引用計數技術包括三種實作方式:一是使用全局引用計數，這樣可以精确的控制整個應用程式子產品的生存期；二是使用針對每個接口一個引用計數跟蹤接口的使用情況，但是對于實作了多個接口的對象，這樣做的效果就是分辨率太細這将導緻無法精确跟蹤每個接口的使用情況，造成管理困難，唯一的好處就是能夠減少資源的消耗;三是使用每個對象一個引用計數這樣可以精确控制對象的生存期，并且在複雜度和資源消耗上能夠達到較好的平衡。BREW接口的引用計數使用方式三，是針對每個接口類或者是應用程式采用引用計數。

應用程式用一個指向接口資料結構的指針來調用接口成員函數，如圖4-5所示。

       圖 4-5： BREW應用程式的接口指針示意

實際上，應用所使用的接口指針也指向一個指針，這個指針則指向一組函數的定義（即接口函數表，又稱為虛函數表，vtable）。每一個接口成員函數的第一個參數必須為指向這個定義這個接口的元件類型的指針（可以參考一下用C模拟C++的過程，在C++的類定義中，每一個成員函數的第一個參數都是隐含的，即編譯系統自動添加的this指針），這是因為接口本身不能獨立存在，它必須依附于某個COM元件而存在。是以這個指針可以提供對象執行個體的屬性資訊，在調用過程中可以知道是在對那個COM對象進行操作。 圖中到圓邊方框之前，定義的都是指針，真正的實作要依賴于COM元件給出的實作，對于客戶來說，隻需要知道應該調用什麼就足夠了，但是對于元件來說就必須考慮這樣的功能應該怎樣實作。接口是客戶程式群組件程式之間的橋梁，接口應該具有不變性，并且一個COM對象也應該支援多個接口。

對于同一個類的所有對象，它們分别擁有不同的資料成員存儲區，但是共享同一份成員函數的拷貝，在不同的對象調用成員函數的時候根據對象隐式傳遞的this指針判别是哪個對象調用了成員函數。對于接口的實作也類似，類似于C++中的資料成員，對于指向虛函數表的指針，每個接口指針都有屬于自己的一份拷貝，而對于提供功能實作的虛函數表，則共享同一份拷貝（圖4-6）。

圖 4-6： BREW中的虛函數表

BREW中的ISHELL_createlnstance方法使用了對象建立型設計模式的抽象工廠模式，它提供了建立一系列相關或者是互相依賴對象的接口，而無須指定他們具體的類，這樣可以隻提供BREW

的接口，而在需要的時候根據具體的ClassID建立具體的實作，一般來說抽象工廠模式有以下的幾個優點:

(1)分離了具體的實作和接口：隻需指定不同的接口和classlD，既可成功建立接口對象，而無須關心是何種實作;

(2)有利于更新産品子產品:當有新的子產品更新的時候，無須更改程式，隻需替換相應的子產品實作，這樣就可以使用新的子產品;

(3) 有利于産品的一緻性;由于classID的唯一性，可以建立指定的對象實作，而不會在有衆多實作的應用中出現混亂。

對于抽象工廠模式難以支援新種類産品的缺點，在BREW 的設計架構中給予消除了，由于重新啟動BREW環境的時候，會對系統範圍内的ClassID 予以重新注冊，是以當新種類加入的時候，隻需要提供确定的ClassID

既可成功建立應用。