Effective C# 原則 34：設計粗粒度 Web API，減少遠端往返開銷
電話訂購 vs. 傳真訂購：API 設計的隱喻 Web 服務或 .NET 遠端處理中，跨機器物件傳輸是最昂貴的操作。將本地介面直接封裝為遠端 API 雖可運作，
Effective C# 第 5 章：善用 .NET Framework 類庫，避免重複造輪子
核心觀念：框架即工具箱 Martin Shoemaker 曾問：「我必須寫這樣的 .NET 代碼嗎？」答案通常是不需要。.NET Framework 提供豐富的
Effective C# 原則 35：優先覆寫虛擬函式，而非使用事件處理常式
兩種回應事件的機制 .NET 類別庫常提供兩種方式讓衍生類別回應系統事件： 覆寫基類虛擬函式（如 OnMouseDown） 附加事件處理常式（如 MouseD
C# 復合指派運算子：簡潔高效的變數更新技巧
從基本算術到復合指派 在 C# 中，若要在變數原值基礎上進行運算並更新，常見寫法為： answer = answer + 42; 為簡化此類高頻操作，C# 提供
C# 迴圈進階：do-while 語句與 break/continue 控制流詳解
do-while 語句：至少執行一次的迴圈 do-while 迴圈的特色在於條件判斷位於迴圈末尾，確保迴圈主體至少執行一次。語法如下： do state
C# 基礎入門：掌握 if 條件判斷語句的完整指南
if 語句的核心語法與運作原理 在 C# 程式設計中，if 語句是控制程式流程的基石。它允許我們根據布林運算式的真偽值，決定執行哪一段程式碼。基本語法結構如下：
Effective C# 原則 36：善用 .NET 運行時診斷，生產環境也能輕鬆除錯
問題常發生在無偵錯環境的使用者機器上。.NET 內建 System.Diagnostics 命名空間提供完整診斷框架，支援執行期/組態檔動態配置，應優先使用而非
Effective C# 原則 37：採用標準組態機制，正確存放應用程式設定
應用程式設定存放歷經 INI、登錄表，皆有缺失：INI 結構受限、易衝突；登錄表需管理員權限、易被破壞。.NET 提供標準組態系統，支援 XML 組態檔、隔離儲
Effective C# 原則 38：擁抱資料繫結，告別手動 UI 同步代碼
傳統 WinForms 開發需手寫大量「控制項↔物件」同步代碼，重複、易漏、難維護。.NET 資料繫結將物件屬性自動映射至控制項屬性，由 BindingMana
Effective C# 原則 39：善用 .NET 驗證框架，捍衛應用程式安全
使用者輸入不可信，可能導致例外、SQL 注入等攻擊。.NET 提供完整驗證框架，Web 與 Windows 表單各有機制，應優先使用內建工具減少手寫代碼。 W
Effective C# 原則 40：按需選擇集合，效能與功能雙贏
「哪種集合最好？」答案是「視情況而定」。.NET 提供陣列、ArrayList、Queue、Stack、Hashtable、SortedList、BitArra
Effective C# 原則 41：優先選擇 DataSet 而非自訂資料結構
DataSet 常因「XML 序列化跨平台困難」與「弱型別容器」被詬病，但若理解其優勢並規避缺點，它能解決多數常規資料問題，開發效率遠超手寫集合。 DataS
Effective C# 原則 42：善用屬性簡化反射，建立可擴展的外掛架構
當必須使用反射時，自訂屬性可大幅降低執行期錯誤風險，將「發現目標」的責任從命名慣例轉移給編譯器與屬性系統。 案例：動態選單命令外掛 需求：啟動時掃描 Addi
Effective C# 原則 43：勿濫用反射，優先採用介面與類別工廠
反射雖能實現動態配置、延遲綁定，但繞過編譯期型別檢查，參數/回傳值皆為 object，極易在執行期發生型別錯誤。大多數情況下，介面、委派、類別工廠等強型別方案更
Effective C# 原則 44：建立應用程式專屬例外類別，提升錯誤處理精度
例外是跨層級報告錯誤的機制，所有錯誤資訊必須封裝在例外物件中。呼叫端透過 catch 不同例外型別執行差異化處理，因此庫作者應提供豐富的例外型別體系。 為何需
Effective C# 第 6 章：雜項主題——安全、診斷、語言演進
本章收錄不適合單獨成章但同樣重要的主題：程式碼存取安全策略、例外處理策略、工具與資源追蹤、ECMA 標準研讀、C# 2.0 遷移準備。這些議題關乎專案長期維護與
Effective C# 原則 45：採用強式例外保證，打造健壯程式
拋出例外會中斷控制流程，若能在管理狀態的代碼中捕獲並恢復，系統更穩健。C++ 社群經六年（1994-2000）驗證出三級例外安全保證，C# 應全盤採用。 三級
Effective C# 原則 46：最小化非託管代碼互操作，三大策略深度比較
.NET 設計初期即重視與既有代碼整合，互操作雖可行，但存在三大開銷：資料封送處理、大量資料跨邊界傳輸效能、開發維護複雜度。若非必要，優先考慮「完全重寫」策略（
