RTTI 有害嗎？TypeMap 動態分類方案證明 RTTI 正確使用可擴展

RTTI 爭議與誤解

本章各設計方案努力避免使用 RTTI，可能留下「RTTI 有害」印象（如可憐的 goto 因印象不佳未入 Java）。實際情況非絕對：錯誤使用 RTTI 才「有害」。避免 RTTI 因其濫用（查找系統每一類型）損害擴展性——新增類型必須找出所有使用 RTTI 代碼，遺漏一個編譯器也無法幫助。

TypeMap：正確使用 RTTI 的擴展方案

RTTI 本身不自動產生非擴展代碼。垃圾回收範例引入 TypeMap：含 Hashtable 容納多個 Vector，介面簡單：add() 新增物件、get() 取得特定類型物件向量、keys() 取得類別枚舉。優勢：遇新類型動態加入，無論何時新增類型（甚至運行期）皆正確接受。基於 c16.Trash 套件 Trash 類型結構（Trash.dat 可復用）。

TypeMap 實作與運作機制

定義簡單：Hashtable + add() 負擔主要工作。新增類型時提取 Class 物件引用，判斷對應 Vector 是否存在於雜湊表：存在則加入、否則以 Class 與新 Vector 作鍵值對加入。filler() 回傳實作 Fillable 介面的匿名內部類，配合 ParseTrash.fillBin() 設計（不僅填充 Vector 也可填充實作 Fillable 的任何物件）。DynaTrash 遍歷 TypeMap 各獨立 Vector 執行 Trash.sumValue()。新類型加入完全不影響此代碼與 TypeMap 代碼。

關鍵觀察

雖嚴重依賴 RTTI，但雜湊表每鍵值對只查找一種類型。新增類型時不會陷入「忘記加入正確代碼」尷尬，因根本無代碼需添加。這顯然是解決問題最圓滿方案。