D11 Component的設計(5)──Exception & Properties

Component裡既然有自己的控制邏輯，那麼期待產生元件設計之初沒有預期到的狀況也是應該的。預期中的狀況可以在Component Controller裡判斷並控制，預期之外或無法處理的狀況就應該拋出Exception告知更上層的控制以便因應。

拋出的Exception應該是這個Component專有的，如此一來可以在層層呼叫的使用時，立即判斷出是在哪個Component裡出現的狀況，進而取得Exception裡的資訊作對應的處理。我們不該傳回基本型態的Exception，也不應與其他Component共用Exception，因為會搞不清楚到底是誰拋出同時也無法取到任何更進一步的資訊，尤其在共用Exception時更會加重使用的關聯。

Component的參數有些人會設計為Component特有的定義檔，在生成時讀取內容並設定。這種方式在設計上很直覺，但衍生的問題是每個Compoent都會擁有至少一個設定檔，當系統擁有上百個有設定檔的Component後，使用者若要調整一些設定就得逐一找到存放的地方打開編輯並儲存。

理想的作法是將所有Component的改變參數都設計傳入類似Properties的集合物件，每個Component的每個參數都擁有唯一的名稱作識別，使用只要建構時傳入或呼叫設定的方法就可以改變Component的設定。所有Component的Properties存放就經由系統統一管理，在需要設定Component時從集中管理的地方找到對應的Properties並傳入即可。

把Component的設定集中到系統管理的最大好處，其實是我們可以針對整個系統的可調整參數設計一個方便使用者編輯參數內容的編輯程式，就類似Windows的控制台的設計概念。