為 PropertyResourceBundle 引入繼承機制：解決國際化資源包維護難題的最佳實踐

PropertyResourceBundle 是 Java 將語系相關文字從程式碼分離的核心機制，支援透過屬性檔實現多語系切換。然而，隨著專案規模擴大，龐大的資源包維護成本劇增。本文提出引入繼承機制，實現資源包的階層式複用與覆寫，徹底解決三種傳統策略的缺失。

三大傳統策略的痛點

• 單一巨型包：所有元件共享一個包，無法重用，任何修改影響全域，維護極其困難。
• 獨立小包：各元件擁有獨立包，重複定義屬性，跨包一致性難以保證（如郵件地址變更需改動所有包）。
• 屬性專用包：程式碼需明確知道每個屬性對應哪個包，維護負擔從資源包轉移到程式碼，耦合度極高。

繼承機制：兼具重用與彈性的最佳解法

核心思想：資源包形成階層結構，子包可繼承父包屬性，亦可新增或覆寫特定屬性。屬性只需定義一次，修改父包屬性自動傳遞給所有子包，大幅降低維護成本。圖示如下：

核心類別設計與實作

1. InheritedPropertyResourceBundle

繼承 java.util.ResourceBundle，持有底層 PropertyResourceBundle 實例與父包引用清單。查找鍵值時，先查本包，找不到則按順序遞迴查詢父包。提供 addRelationship()、removeRelationship() 動態調整繼承鏈。

2. RelationshipLoader

從 <resource_base_name>.relationships 檔案載入父包關係，格式簡單、無需國際化。若找不到關係檔，退化為普通 PropertyResourceBundle 行為，確保向後相容。

3. InheritedBundleManager（單例）

管理所有 InheritedPropertyResourceBundle 實例，以「包名 + 語系 + ClassLoader」為鍵快取，避免重複建立導致記憶體暴增。所有用戶端必須透過此管理器獲取實例。

已知限制與應對

• 循環繼承：目前不檢測，可在 addRelationship() 中加入循環檢查拋出異常。
• 獲取實例方式變更：需改用 InheritedBundleManager.getInstance().getBundle(...)，而非標準 ResourceBundle.getBundle()。
• 型別差異：實作繼承 ResourceBundle 而非 PropertyResourceBundle，若用戶端強依賴後者需調整代碼。

結語

繼承機制在保留現有國際化功能的同時，引入物件導向的重用語義：既能共享通用資源，又允許彈性擴展與覆寫；維護集中化、零侵入式遷移現有資源包。採用此架構開發全國際化 Java 應用，將顯著簡化設計並提升資源包重用度。