2007年8月15日 星期三

D04 Component的需求規格與設計

架構設計完成後,可以得到所有新增元件的清單與每個元件應有的屬性與方法,這些便是對Component的功能需求。

我們把視野縮小到Component,可以感覺它就像一個縮小的系統那樣有限定的範圍,Interface的設定就等同於對於Component的功能需求。有人認為只要定義好Interface,Component要怎麼設計就不需要管,只要符合規格並通過測試就好;這個想法在系統層級時已經討論過,在這裡基於“每一個程式的存在都有它的意義“的想法,Component與系統一樣都是需要設計的。

將Component視為積木並沒有什麼不對,在有不同需要的時候整個置換成另一個。但是我們已經知道在前面提到的印表機案例裡,整個抽換的方式會造成的幾個問題:傳入的Model只符合特定實作、Controller與動作無法分割而有過多重覆的程式碼、支援新的實作時只能copy-paste再修改。

Component的reuse是提升系統開發效率其中的一項指標,但我不認為reuse是整個Component拔掉再換一個,而是使用同一個Component並使用不同的傳入來改變內部的行為。就像一塊具有螺旋漿的積木,使用者可以用手撥動令它旋轉,而不是轉到不同方向時就拿另一塊積木來取代。設計時儘量將變動封裝在Component內部,因應系統需求而需要更換不同Component的設計則在系統上實現。

選用適當的元件用適當的方式快速堆疊出整個系統是我們對軟體工廠的期待;介面的存在提供了如同積木般連接的規格,但是Component並不是只是用積木的方式接起來就可以,在介面上傳遞的資料才是它的精神。

沒有留言:

張貼留言