N11 令人感到麻煩的設計(15)──避免將參數放在設定檔

決定不用程式碼寫死使用關係的同時，表示我們必須在某個地方記錄對應的關係並在執行時取得。通常的最快作法是將參數放在properties檔案，再使用ResourceBundle方式讀入為Properties取用；不過使用時再多往幾個方向思考一下，或許會有不同的決定。

檔案位置的固定。很多時候為了方便設計與管理，Component的參數檔案會被指定放在一個固定的地方，而且通常是使用它的Package裡。這樣的放置會造成設定檔被“綁死”在那個地方，無法應付系統要求要集中所有的設定檔方便管理的需求。

檔案類型的固定。在設計上採用傳入檔案所在的URL後再於內部讀取內容，這樣的設計可以讓設定檔在任何存取得到的地方。不過取得的來源就只限於properties檔案，要是客戶另外有xml或是資料庫來存放設定的話，就沒法動態由不同的來源產生。

雙向讀寫的要求。即使設定檔由外部組成Properties物件再傳入Component的作法可以滿足以上的想法，但是Properties的特性是只能讀取的。設定一般來說是允許客戶修改的，直接修改檔案內容雖然快卻有修改內容發生錯誤的狀況，此時可能需要選用別的物件。

靈活替換的判斷資訊有很多存在於設定檔，針對以上各方面的考量，在設計上我會定義自己的設定檔物件，由客戶決定怎麼生成Component需要的設定來滿足以上的想法；當然，這個設定檔物件是存放在元件庫裡的。