為什麼 Java 繼承被認為有害：組合優於繼承的深度論證

面向接口編程將變化點隔離，支撐敏捷開發中「並行設計與編碼」的核心需求。

2. 破壞封裝：脆弱基類問題

子類繼承父類實現細節，父類修改私有邏輯（如新增方法、調用關係變更）可能導致子類行為異常。經典案例：Stack extends Vector 導致 push/pop 與 insertElementAt 邏輯衝突，指針錯位產生「垃圾元素」。

補救措施（覆寫所有可變方法、拋出異常）將編譯期錯誤轉為運行期異常，且違背接口隔離原則。

3. 語義違背：「是一種」關係的濫用

繼承本意是封裝「可變性」（同一繼承體系下不同具體行為），而非單純代碼復用。MonitorableStack extends Stack 看似合理，但依賴父類 pushMany 調用 push 的實現細節，一旦父類優化改為批量操作，子類監聽邏輯失效。

組合/聚合：正確的復用之道

class Stack {
    private List<Object> data = new ArrayList<>();
    private int pointer = 0;
    public void push(Object o) { data.add(pointer++, o); }
    public Object pop() { return data.remove(--pointer); }
    // 無繼承，完全封裝內部數據結構
}

優勢：

• 內部實現完全可變，不影響客戶端
• 無脆弱基類風險
• 可精確暴露所需接口（如無 removeRange）
• 支持運行時動態替換內部策略（Strategy 模式）

設計原則總結

1. 開閉原則：對擴展開放，對修改關閉 → 依賴抽象/接口
2. 里氏替換原則：子類必須能無縫替換父類 → 嚴格限制繼承語義
3. 依賴倒置原則：依賴抽象，不依賴具體 → 工廠模式隔離創建
4. 合成復用原則：優先組合/聚合，非必要不繼承
5. 接口隔離原則：多個專用接口優於單一臃腫接口

何時才使用繼承？

僅當滿足所有條件時：

• 子類真正是父類的「特化」（Is-A 關係嚴格成立）
• 父類設計為被繼承（文檔化、受保護方法、無脆弱性）
• 不需組合即可優雅實現

其餘場景，**組合優於繼承** 是鐵律。