導出與導入：最小知識原則
- 導出： 僅公開必要套件 (API)，隱藏實作細節。預設**不導出**，白名單機制。
- 導入： 僅引入所需套件，忽略同模組其他套件。**按需導入**，而非「買下整間商店」。
購物類比：為何按需導入更優？
我逛街只買清單上的東西，不在乎哪家店；妻子進店買滿全場。若店換貨架，她買到不需要的、缺真正需要的，還得跑多家店配齊電池、配件……這就是 **扇出效應**，Maven 傳遞性依賴常陷入此陷阱。
OSGi 強制宣告精確導入套件，避免傳遞性依賴爆炸。
導入導出粒度：為何選「套件」？
| 層級 | 評估 |
|---|
| 方法/欄位 | 荒謬：類別非設計為運行時可分割，檢查成本極高。 |
| 類別 | 數量過多，同包類別高度耦合，分割不合理。 |
| 整個模組 | 無法隱藏實作，退化為單體。 |
| 套件 | 最佳平衡：內聚性高、數量適中、可整包導入導出、內部實作可放非導出套件。 |
套件接線與動態模組
- 容器建立類別載入器，根據導入導出建立 **Wiring** (委派關係)。
- 所有導入成功接線 → Bundle **Resolved** → 可用。
- 動態安裝/更新/解除安裝：框架精確感知影響範圍，變更狀態；解除前發出事件讓 Bundle 乾淨關閉。
- 動態性非強制：不使用動態特性仍能享受模組隔離與版本管理紅利。
版本控制：語義版本與範圍匹配
- 導出者宣告版本 (如
1.0.0)。
- 導入者指定接受範圍 (如
[1.0.0, 2.0.0) 含 1.0.0 至 2.0.0 不含)。
- 接線時版本落在範圍內即匹配。
- 語義版本規約 (強烈建議)：
- 主版本號：不相容 API 變更。
- 次版本號：向後相容功能新增。
- 修訂號：向後相容缺陷修復。
- 現實世界第三方庫常不遵守 → 需謹慎設定寬鬆範圍或人工驗證。
