C++ 多重繼承本質探討：從 Eiffel、Java 到 C++ 的演進與取捨

多重繼承是物件導向語言設計中極具爭議的特性。Eiffel 與 C++ 直接支援，Java 則以介面機制替代。本文深入剖析多重繼承的核心難題、各語言的解決策略與工程權衡。

核心爭議：複雜性 vs 表達力

Sun 主張多重繼承帶來諸多問題，C++ 的實作方式更印證此點。看似簡化設計的理由（如混入 utility 函數）經證明意義有限。核心難題清單極長：

• 同名資料成員的衝突策略：合併？區分？相容性判斷？
• 鑽石繼承下的基類實體唯一性問題
• 建構/解構順序的複雜語義
• 型別轉換的歧義性

Java 介面機制：抽象化的妥協

Java 介面僅允許抽象方法與常數欄位，消除了實作衝突選擇的必要。常數欄位在多重實作時自動合併，但若常數值不一致將導致編譯錯誤。雖失去混入非抽象實作的能力，但可透過組合模式達到同等效果，不構成嚴重缺失。

Eiffel 的優雅解法：聲明式消歧義

Eiffel 未引入單獨介面機制，而是在繼承子句中完整解決：

• renaming：重新命名衝突特徵確保唯一性
• redefining/undefining：調整匯出策略
• select：顯式消除歧義
• 編譯器強制語義清晰，程式碼簡潔穩健，程式設計師保有完全控制權

C++ 的操作符消歧義：事後補救的代價

C++ 採用域解析運算子 :: 於使用點消除歧義。缺點顯著：

• 歧義直到使用時才暴露，非聲明期即可發現
• 程式碼散佈大量 ::，降低可讀性與擴充性
• 基類變更可能波及所有衝突使用點，維護成本高

ANSI 委員會曾考慮引入 renaming 但被否決，專家尚需兩週評估，可見複雜度。Stroustrup 著作中展示的替代方案同樣晦澀。

其他語言的選擇

• BETA：拒絕多重繼承，理由為缺乏深刻理論基礎且技術實作過於複雜
• Ada 95：僅支援單繼承（標記型別擴展）
• Flavors：多重繼承與順序相關，(A,B) ≠ (B,A)

直接重複繼承的差異

Eiffel 允許 class B inherit A, A end，C++ 則禁止 class B : public A, public A。這反映了兩語言對型別系統純度與實作複雜度的不同取捨。

工程結論

多重繼承相關問題可系統性識別並優雅解決（Eiffel 證明）。但 C++ 的實作機制導致高認知負擔與維護成本。現代設計傾向：優先使用組合、介面隔離、策略模式，僅在極少數領域模型強制要求時謹慎使用多重繼承，並嚴格遵循「介面繼承為主、實作繼承為輔」原則。