繼承與介面的本質區別：從「是一種」到「能做什麼」的設計哲學轉變

繼承的副作用：過度耦合與特徵濫用

繼承旨在複用父類實現，無需了解細節即可獲得所需特徵。然而，子類往往只需父類部分特徵，繼承卻強制攜帶所有特徵——包括不需要甚至極力避免的特徵。在支援多重繼承的語言中，這極易引發難以發現的錯誤。物件導向語言因此衍生出各種限制機制（如 final、private、存取修飾符）來約束子類對父類成員的使用。

經典比喻：狗與猴子的故事

假設主人希望狗會爬低矮的樹，但不希望它像猴子能倒掛樹尾、飛簷走壁。若讓狗繼承猴子，將獲得所有猴子特徵，違背原始意圖。這正是繼承「過度給予」的弊端。

介面導向設計：精準賦能與解耦

設計模式強調面向介面編程。猴子擁有「爬樹」與「尾巴倒掛」兩個介面。主人只需狗實作「爬樹」介面，即可獲得目標能力，完全避開「尾巴倒掛」副作用。介面定義「能做什麼」，而非「是什麼」，實現精準能力賦予。

技術演進趨勢：從繼承到介面的範式轉移

OO 技術發展多年，明顯趨勢是繼承使用減少，介面使用普及。對比 JDK 早期類庫（大量繼承層級）與新增類庫（幾乎全面採用介面），可清晰感知編程風格演變。介面非繼承替代品，而是互補：當關注行為能力而非具體實現類型時，介面提供極致靈活性。

實戰靈活性展示

// 介面定義
interface Climable { void climb(); }
interface Bitable { void bite(); }

// 具體實現
class Dog implements Climable, Bitable { ... }
class Monkey implements Climable { ... }
class Cat implements Climable, Bitable { ... }

// 使用端：只關注能力，不關注具體類型
Climable climber = getClimber(); // 可能是 Dog、Monkey 或 Cat
climber.climb();

// 組合能力需求
ClimableAndBitable hunter = getHunter(); // 實作雙介面
hunter.climb();
hunter.bite();

// 運維期替換實現：發現貓更靈活，直接替換 Dog 為 Cat，調用碼零修改

核心原則總結

• 繼承：表達「是一種」關係，適用於強同構、行為高度一致的類別體系。
• 介面：表達「能做什麼」契約，適用於跨類別的能力抽象、多型解耦、插件式架構。
• 組合優於繼承：透過介面組合能力，而非繼承實現，獲得更高內聚、低耦合、易測試、易維護的系統。

結語

從繼承走向介面，是軟體設計從「實現復用」向「契約導向」成熟的標誌。現代框架（Spring、Dubbo 等）皆以介面為核心，構建可擴展、可替換的企業級架構。