Effective C++ 條款27：盡量減少轉型動作——新式轉型、替代設計與封裝策略

轉型破壞類型系統

C++ 類型系統旨在防止類型錯誤，但轉型（cast）繞過編譯器檢查，可能引入難以發現的運行時錯誤。舊式轉型 (T)expr 或 T(expr) 尤其危險。

四大新式轉型回顧

• const_cast：去除 const/volatile，唯一具備此能力。
• dynamic_cast：安全向下/橫向轉型，需 RTTI，失敗返回 nullptr 或拋出異常，有運行期開銷。
• reinterpret_cast：低級位模式重新解釋，依賴編譯器，不可移植。
• static_cast：強制隱式轉換（數值、指針上行、void* 轉具體指針），不可去除 const。

為什麼優先使用新式轉型？

1. 易於識別：代碼中一眼可見，便於審查與工具掃描。
2. 職責單一：編譯器能診斷濫用（如用 static_cast 去除 const 會報錯）。

三大減少轉型的實戰策略

1. 避免轉型——重新設計

若設計頻繁需要 dynamic_cast，說明繼承體系可能違反 Liskov 替換原則。嘗試：

• 將操作上移至基類為虛函數，派生類覆寫（多態替代類型查詢）。
• 使用 Visitor 模式分離演算法與對象結構。
• 採用 variant/any（C++17）或類型擦除技術替代繼承體系。

2. 封裝轉型——隱藏細節

若轉型不可避免，將其封裝在函數內部，客戶代碼調用函數而非直接轉型。

// 不好：到處散落 dynamic_cast
Derived* d = dynamic_cast(basePtr);

// 好：封裝
Derived* getDerived(Base* b) {
    return dynamic_cast(b); // 單一受控位置
}

3. 寧用新式勿用舊式

新式轉型語法醒目、語義明確、編譯器可檢查，舊式轉型在現代 C++ 中無任何優勢。

性能關鍵代碼中的特別提醒

在注重效率的代碼中避免 dynamic_cast（運行期類型檢查有開銷）。若必須用，考慮緩存結果或改用靜態多態（CRTP/模板）。

總結

1. 能不用轉型就不用，通過多態/泛型/變體設計消除。
2. 必須用時，優先選擇 static_cast、const_cast，謹慎用 dynamic_cast，極少用 reinterpret_cast。
3. 將轉型封裝在函數中，縮小影響範圍。
4. 全面棄用 C 風格轉型。