2007年8月21日 星期二

D10 理論串接實作的瓶頸(8)──實現軟體工廠的機會

前面提過所有功能的目的都在於處理資料,以封裝Component的概念來說,唯一的輸入與輸出物件就是Component Model。有很多人說過軟體工廠是不易實現的理想,假使工廠不管生產什麼樣的元件都是處理基本型態相同的Component Model,這樣一來是不是有機會實現呢?

上一篇提到在Model本質不同時有三種資料轉換的方式,每一種都需要另外撰寫程式才能讓資料在不同模組之間轉換:第一種必須寫存取資料的實作,第二種必須撰寫Wrapper程式,第三種則必須寫搬動資料的動作。如果,我是說如果,一間公司裡所有Component Model與Data Model的根本都是相同性質的基本資料類別(比如說是Map),每個Component的方法都附有一個方法將傳入的基本資料類別,包裝為Component Model後傳回再傳入Component處理,處理時對基本資料類別的所有操作都可以自動反應回系統。

2006年開發系統時加上了這個Common Model的想法,向下對應數種不同型態檔案讀回的內容,實際把檔案讀入後變為Common Model,實作時都是操作Common Model,使用者根據檔案類型呼叫對應的Parser後都是Common Model。Common Model再往上可分支實作出不同類型的Data Model給不同的系統使用,但是底層的處理都是通用的。利用這個概念應用在Model與Controller上,我讓兩個有點類似的系統共用了相同的處理核心,使得Use Case的再使用率達到70%以上。(註)

開發第二個系統的快速(花費人力大約佔第一個系統的五分之一)讓我對於軟體工廠的思維有相當大的信心。往後的專案只要先定義好公司使用的基本資料類別,我相信軟體元件化的理想是可以落實的。

註:開發的兩個系統是可以同時使用的,使用者可以自由切換到任一個系統執行任一個功能而不需重新啟動程式。

沒有留言:

張貼留言