痛點：泛型帶來的冗長聲明
Java 5 引入泛型雖然增強了類型安全，但也導致聲明極其冗長：
// Java 5 前
Map socketOwner = new HashMap();
// Java 5 後
Map> socketOwner = new HashMap>();
類型參數在聲明與初始化處重複，違反 DRY 原則。缺乏 typedef 機制，開發者開始尋找變通方案。
反模式誕生：繼承充當「窮人的 typedef」
// 典型反模式
public class SocketUserMap extends HashMap> { }
// 使用時簡潔了
SocketUserMap socketOwner = new SocketUserMap();
看似完美解決冗長問題，實則引入嚴重副作用。
三大致命缺陷深度剖析
1. 類型不兼容：擴展 ≠ 類型別名
C 語言 typedef 創建的是等價類型，可自由互換。但 Java 繼承創建的是子類型：
class StringList extends ArrayList {}
class UserList extends ArrayList {}
// 錯誤：不能將 List 傳給要求 StringList 的方法
void process(StringList list) {}
process(new ArrayList()); // 編譯失敗
process(new UserList()); // 編譯失敗，雖然同源
這導致 API 使用者被強制綁定具體偽類型，嚴重破壞多態與介面導向編程。
2. 病毒式傳染：跨庫兼容性崩潰
若兩個獨立庫各自定義 StringList，它們是完全不同的類型，無法互通。使用者必須在兩者間選邊站，或編寫大量轉換代碼，這正是 C 語言「頭文件地獄」在 Java 的重現。
3. 過度具體化：喪失介面抽象優勢
偽類型通常直接繼承具體類（ArrayList）而非介面（List），鎖死實現細節，違反「面向介面編程」原則，使 API 脆弱難維護。
正解：類型推斷與工廠方法
利用編譯器類型推斷能力，定義靜態工廠方法：
public static Map newHashMap() {
return new HashMap();
}
// 使用時：類型參數自動推斷
Map> socketOwner = Util.newHashMap();
優勢：零運行時開銷、保持介面類型、無傳染性、符合 JDK 集合框架設計哲學（如 Collections.emptyList()、Guava Maps.newHashMap()）。
現代 Java 的進一步改進
- Java 7 鑽石操作符：
new HashMap<>() 簡化右側聲明
- Java 10 var 關鍵字：
var map = new HashMap>(); 完全消除冗長
- 類型別名 (JEP 301 探索中)：未來可能引入真正的
typealias
總結
偽 typedef 反模式是對泛型冗長的短視妥協，以類型系統完整性為代價換取暫時的敲鍵便利。正確做法是擁抱類型推斷、工廠方法、現代語法特性，在保持類型安全與多態性的前提下減少樣板代碼。架構設計中，任何「為了省事而破壞類型體系」的做法都應警惕。
