基於BREW平台的松耦合設計III－可移植、可複用軟體的設計原則

 

基於BREW平台的松耦合設計III－可移植、可複用軟體的設計原則

毛曉冬 2007-10-26

 

一、    概述：

本文主要闡述基於BREW平台的可移植/可複用軟體的最通用的設計原則，以便利用BREW平台自身的優勢，加快開發。

 

二、    高低層（應用和底層實現）組件間的設計原則：

 

 

 

高低層組件間的設計原則，如描述的那樣，歸納而言就是：

高層組件依賴介面抽象，不依賴與低層實現。

低層實現依賴介面抽象，不依賴高層組件。

其本質，就是要將高層組件和低層組件間進行解耦，通過介面抽象聯絡在一起，每一部分都可以單獨的變化，這種變化被封裝起來，對外體現不變的抽象（介面）。這使得，當系統（需求）變化時，兩者可以獨立的變化而不影響對方，從而達到可移植，可複用，可擴充性。

 

該原則對應到BREW，其實就是要求App只允許以介面方式訪問一切服務（實現）。即，App就是高層組件，通過BREW的介面（標準的，或者擴充的），訪問底層的服務。通過介面隔離耦合。

 

在BREW中，高層組件依賴低層組件的情況，典型的就是App繞過介面抽象，直接調用了底層實現（以函數或者全域變數的方式）。而低層組件依賴高層組件的情況，典型的就是介面的內部實現中，直接引用了App的類成員或者直接發事件給特定CLSID的App。

  

   對於這種違背原則的做法，直接的後果，就是由於沒有隔離耦合，進而沒有隔離/封裝變化點，從而導致面對需求變化時，可重用，可移植，可擴充性的低下。因為對於上層應用，隨著客戶需求的變化，可能發生改變，這是一個變化點，需要封裝。對於底層實現，隨著硬體，平台的差異，也可能發生變化，這又是一個變化點，也需要封裝。此時，我們就需要引入一個介面抽象層來隔離，封裝變化點。從而保證高層組件（App）和低層組件（底層實現）的可移植性，因為它們都依賴於介面抽象。典型的，在新項目中，上層UI可以直接移植。對於底層實現，只需要保證對上依賴的介面抽象不變即可，這一步（底層實現）可以和UI同步的進行。

       反之，則會帶來可觀的額外負擔！且隨著時間和變化的推進，負擔將越來越大。

 

 

 

 

三、    高層間（應用間）的設計原則：

 

 

 

 

，高層間的設計原則，應該是：

使用一組規約解耦高層組件間的通訊，將綁定延遲到運行時。對應與BREW，這裡的高層組件很明顯就是App，這裡的規約可以是模組暴露的擴充介面，MIME Type等等任何可以用來解耦BREW App間互動的手段。

這種設計原則的好處在於，每個應用對外提供的服務和從外界索取的服務都通過一組規約來定義，從而避免了組件間的直接互動。

 

這種設計原則典型的用途在於，App的移植或者替代升級。只需要實現升級後應用的所有必要規約，其他的應用就不需要作任何變動。

註：如果能找到比事件更好的方案，就盡量不要使用事件。

 

四、    總結：

基於本文提到的原則，其實將一個系統抽象來看，最重要的就是一組組件間（應用間）的規約，以及一組高/低層組件間的依賴抽象（介面）。此時，不管是移植整個平台，還是單獨升級某個應用或者底層實現，都變得簡單而可控。

 

附：

本文所指的介面，是對象的一種規格，具體到語言層次，就是C++中的純虛基類，Java/C#中的介面，或者C中的虛表。在編譯期代表抽象，在運行期綁定實現，決不是簡單的（全域，靜態）函數和（全域，靜態）變數。