框架提供介面 FrameworkInterface (含 500+ 方法) 及預設實作 DefaultImpl。開發者僅需覆寫其中一個方法，但若直接 implements FrameworkInterface 則必須實作所有方法。
| 方案 | 做法 | 優點 | 缺點 |
|---|---|---|---|
| 繼承預設實作 (推薦) | class MyImpl extends DefaultImpl { @Override void targetMethod() { ... } } | 零樣板碼、自動繼承所有預設行為、僅覆寫需求 | 需框架提供非 final 的預設實作類別 |
| 委託/裝飾模式 | 持有 DefaultImpl 實例，介面方法轉呼叫，僅覆寫目標方法 | 不依賴繼承、可組合多個實作 | 需手寫 500 個轉發方法 (可用 IDE 產生/動態代理) |
| 動態代理 | Proxy.newProxyInstance(..., (proxy, method, args) -> method.equals(target) ? custom() : method.invoke(defaultImpl, args)) | 極度精簡、執行期決定 | 效能稍低、除錯困難、僅適用介面 |
| 介面預設方法 (Java 8+) | 框架若將介面方法改為 default void method() { ... }，實作類可選擇性覆寫 | 語言層面支援、無需額外類別 | 需框架升級介面定義、無法存取私有狀態 |
// 框架提供
public class DefaultImpl implements FrameworkInterface {
public void method1() { ... }
// ... 500 個預設實作
public void targetMethod() { /* 原始邏輯 */ }
}
// 你的程式碼
public class CustomImpl extends DefaultImpl {
@Override
public void targetMethod() {
// 你的自訂邏輯
super.targetMethod(); // 可選：保留原邏輯
}
}
AbstractBase 或 DefaultImpl。AbstractBase 實作所有方法拋出 UnsupportedOperationException，再繼承它 (風險：漏改會丟例外)。框架設計者應遵循 **「介面隔離原則 (ISP)」** 將大介面拆小，或提供 **「預設實作類別」** 供擴充，避免使用者陷入「為了改一行程式碼，寫五百行委託」的困境。
