解析而非驗證：歷年 C++ 實踐演進

背景

本文探討了 Alexis King 著名的程式設計哲學「解析，而非驗證」（Parse, don't validate）如何應用於 C++ 開發。作者透過 C++98 到 C++23 的演進，展示如何利用型別系統確保資料在實例化時即為有效狀態，從而消除後續程式碼中冗餘的驗證邏輯，並以日期解析作為具體案例，說明不同時代的語言特性如何影響這一範式的實踐。

社群觀點

在 Hacker News 的討論中，社群對於「解析，而非驗證」的核心價值達成高度共識，即透過型別系統提供解析成功的證據，並利用存取控制（如私有建構子）防止無效資料的產生。然而，針對 C++ 的具體實現，討論呈現出多樣的技術辯論。部分評論者指出，原文中 C++11 的範例較為薄弱，因為其拋出異常的建構子未能有效阻止無效日期（如 2 月 30 日）的生成，真正體現該哲學的關鍵在於 C++17 或 C++23 引入的靜態工廠模式與 std::expected，這類機制讓型別本身成為「正確性」的證明，而非僅是資料的容器。

關於程式範式的討論也十分熱烈。有觀點認為這種模式在函數式語言（如 Haskell 或 Rust）中更為自然，因為這些語言擁有更強大的型別系統來處理解析失敗的情況。但反對者認為，物件導向語言如 C++ 同樣能自然地透過類別封裝來達成目標，關鍵在於開發者是否願意克服「懶惰」，將原始字串封裝成更具體的型別。此外，針對 C 語言是否能實踐此範式，社群產生了分歧：有人主張 C 語言可以透過回傳指標或錯誤碼來模擬，但批評者反駁，由於 C 語言缺乏嚴格的型別約束與存取控制，無法像強型別語言那樣在編譯階段就保證「無效狀態不可表達」。

此外，社群也對範例中的細節提出了實務上的挑戰。例如，將出生年份限制在 1900 年之後是否過於武斷，以及 C++ 缺乏類似 Rust FromStr 這種標準化解析介面的遺憾。有評論者提到，雖然 C++23 引入了 std::print，但仍缺乏對應的 std::scan，這使得在不預先建立「空物件」的情況下進行解析變得相對困難。整體而言，社群認為這不僅是技術選擇，更是一種設計思維的轉變：從「檢查資料是否正確」轉向「建構保證正確的資料結構」。

延伸閱讀

在討論中，參與者提到了幾本對物件導向設計與 C++ 風格有深遠影響的經典著作，包括 1994 年出版的《設計模式》（Design Patterns: Elements of Reusable Object-Oriented Software），以及 Grady Booch 關於物件導向分析與設計的系列書籍。這些資源被用來論證，雖然「解析，而非驗證」在現代函數式編程中被發揚光大，但其核心的型別安全與封裝思想，早在 1990 年代的 C++ 開發實務中便已存在。