D17 理論串接實作的瓶頸(9)──專案思維與元件思維

從系統的角度來看，需要呈現給使用者看到的是View、Model、顯示狀態的Message與處理中記錄的Log，會從系統外部來的有Properties與Model。元件如果像縮小的系統，是不是應該也要考慮這些與輸出入有關的物件呢？

我的答案是否定的。在前面我所切分的元件層次裡，主要有功能與功能的Controller、傳入的Properties、再加上一個Implementation用Factory處理功能的切換與用Wrapper把傳入的基本Model轉變為Component Model。View、Message與Log呢？它們只允許存在於系統？

元件應該是一個獨立的單位，它最重要的工作是完成我們需要的功能，並在無法處理時回報狀況與資訊。View的作用在於執行前輸入資料並於執行後顯示結果，這些資料其實都屬於Model的內容，元件只要能處理Model就可以工作；如果把View寫進元件裡頭，要是下一個系統使用的View不相容時應該又會是一樁慘劇。基於這個想法，元件也不應拋出提示的Dialog，我們可以規定功能的完整執行要進行三次呼叫，由上層的系統來控制每一次呼叫之中要做哪些提示動作。

Log的問題也很類似，把這個系統使用的Log物件傳入元件裡記錄，要是下次用的是另一個種類呢？Message則會牽涉內容的客製化與多國語言的問題，同樣不應該進入到元件裡面處理。每個元件的輸入Properties名稱與執行後的Message內容都應該設定成唯一存在的id，參數與資訊都使用代號後就可以在系統層級儘情地客製化為喜歡的樣子；當然，元件本身應該提供一個預設範本供系統直接使用或參考修改。