Java 理論與實踐：偽 typedef 反模式——泛型時代的類型別名陷阱

Java 5.0 引入泛型極大增強類型系統表達力，卻也帶來聲明冗長問題：Map<Socket, Future<String>> 需重複編寫類型參數，違背 DRY 原則。缺乏 typedef 機制下，部分開發者濫用「擴展泛型類不加功能」模仿類型別名，形成偽 typedef 反模式。本文深度剖析其危害與正確替代方案。

泛型聲明冗長痛點

// 老寫法（原始類型，無類型安全）
Map socketOwner = new HashMap();

// 新寫法（參數化類型，冗長）
Map<Socket, Future<String>> socketOwner = new HashMap<Socket, Future<String>>();

類型參數在聲明與初始化處重複，強迫開發者違背「不要重複自己」原則。雖 IDE 自動補全緩解輸入負擔，但代碼閱讀噪音依然存在。

偽 typedef 反模式：繼承泛型類偽裝類型別名

// 反模式示例：擴展 HashMap 但零功能
public class SocketUserMap extends HashMap<Socket, Future<String>> { }

// 使用時簡化為一行
SocketUserMap socketOwner = new SocketUserMap();

看似達成簡化聲明目標，實則引入嚴重副作用：

1. 擴展 ≠ 類型等價（破壞里氏替換原則）

C/C++ typedef 定義的別名與原類型完全等價，可自由互換。Java 擴展創建的是新的不兼容類型：

class StringList extends ArrayList<String> {}
class UserList extends ArrayList<String> {}

void validateUsers(UserList users) { ... }
UserList lookupAll(StringList names) { ... }

雖 StringList、UserList 皆擴展 ArrayList<String>，但它們互不兼容，亦不可向 ArrayList<String> 多態賦值。客戶代碼被綁定具體偽類型，喪失多態靈活性。

2. 構造函數繼承缺失

若父類無無參構造函數，子類必須顯式聲明所有構造函數並委托 super()，樣板代碼抵消簡化收益。

3. 洩露實現細節，阻礙重構

客戶代碼依賴具體子類而非介面（如 List<String>），違背「面向介面程式設計」原則，未來替換實現（如換成 LinkedList）極其困難。

正確替代方案

方案一：型別推斷（Java 7+ 鑽石操作符）

Map<Socket, Future<String>> socketOwner = new HashMap<>(); // 編譯器推斷類型參數

方案二：工廠方法封裝構建邏輯

public static <K, V> Map<K, V> newHashMap() { return new HashMap<K, V>(); }
// 使用
Map<Socket, Future<String>> socketOwner = newHashMap();

方案三：領域模型封裝（推薦）

而非空殼繼承，賦予類領域語義與行為：

public class SocketUserRegistry {
    private final Map<Socket, Future<String>> map = new HashMap<>();
    // 提供業務方法：register、lookup、notify 等
}

這才是物件導向正確建模：封裝數據結構，暴露領域操作，而非暴露內部集合類型。

總結

偽 typedef 反模式是泛型時代的「窮人捷徑」，表面簡化聲明，實則犧牲類型系統靈活性、違背封裝原則、增加維護負債。Java 故意不提供 typedef，迫使開發者正視類型複雜度，通過鑽石操作符、工廠方法、領域建模等正規手段管理複雜性。真正的簡化來自於更好的抽象，而非類型系統的投機取巧。