Effective C# 原則 16：最小化垃圾產生
垃圾回收器（GC）雖高效，但堆積物件配置與回收仍比堆疊操作昂貴。頻繁配置短暫參考型別會拖垮效能。掌握三大技巧，減輕 GC 壓力： 1. 將頻繁使用的區域變數提
Effective C# 原則 17：最小化裝箱與拆箱操作
實值型別是資料容器，不支援多型；.NET 以單一繼承的參考型別 System.Object 為根。為連結兩者，框架引入裝箱（實值型別 → 參考型別，在堆上建立「
Effective C# 原則 18：實作標準 Dispose 模式
佔用非受控資源（檔案控制代碼、資料庫連線、GDI+ 物件、COM 物件等）的型別，必須正確釋放資源。.NET 提供標準 Dispose 模式，配合 IDispo
Effective C# 原則 19：優先定義與實作介面，而非繼承
抽象類別在繼承體系中扮演「共同祖先」角色，提供預設實作；介面則定義「原子化功能合約」，任何型別皆可實作。兩者各有千秋，核心差異在於：繼承表達「is-a」關係，介
Effective C# 第三章：用 C# 表達你的設計意圖
C# 語言為軟體設計引入了一套全新的語法詞彙，讓開發人員能清晰地與維護者、擴展者以及使用者溝通設計意圖。所有 C# 類型皆生長於 .NET 執行環境之中，這個環
Effective C# 原則 20：辨析介面實作與虛擬函式覆寫的本質差異
表象相似，實則迥異 乍看之下，介面實作與虛擬函式覆寫都讓衍生類別提供具體實作。但兩者語意、繫結機制、版本演進規則完全不同。 介面方法非虛擬：靜態繫結與隱藏機制
Effective C# 原則 21：使用委派實作回呼，支援非同步與多目標通知
回呼：非同步服務與用戶端的資訊回饋 委派是 C# 實作回呼的核心機制：型別安全的函式參考容器，可包含靜態/實例方法，支援多播（串聯多個目標）。 多播委派的兩大
Effective C# 原則 22：以事件定義對外介面，實現鬆散耦合通知機制
事件：基於委派的型別安全通知契約 事件讓型別對外發布通知，任意數量消費者可訂閱處理。發送者無需知曉消費者細節，實現鬆散耦合。 基礎實作：Logger 範例
Effective C# 原則 23：避免回傳內部物件參考，保護封裝邊界
「唯讀屬性」的陷阱 回傳參考型別的唯讀屬性，呼叫端仍可透過參考修改內部物件狀態： _ds; // 唯讀屬性 } // 呼叫端 var ds = bizObj.
Effective C# 原則 24：選擇宣告式編程，以屬性替代命令式邏輯
宣告式 vs 命令式：意圖與實作的分離 命令式：撰寫方法逐步指示「如何做」。 宣告式：以屬性宣告「要做什麼」，執行時期由執行環境自動實現行為。 C# 中套用
Effective C# 原則 25：讓型別支援序列化，確保物件持久化與圖形完整性
序列化：型別的核心義務 物件持久化是基本功能。若型別不支援序列化，所有包含該型別為成員或基類的類別都將無法正確序列化，強迫消費者繞道手寫序列化邏輯，甚至因無法存
Effective C# 原則 26：實作 IComparable 與 IComparer 建立型別排序關係
兩大介面：自然順序與自訂順序 IComparable：定義型別自然順序（如字串按字典序、數值按大小）。 IComparer：提供替代排序順序（如依收入排序客戶
Effective C# 原則 27：避免實作 ICloneable，簡化複製語意與繼承負擔
ICloneable 的模糊契約 ICloneable 定義單一方法 Clone()，但文件同時支援淺層複製與深層複製，未強制規範。這導致： 消費者無法得知複
Effective C# 原則 28：避免轉換運算子，防止隱性副作用與封裝破壞
轉換運算子：看似便利、實則危險 C# 允許定義隱性/顯性轉換運算子，宣告型別可替換性。但這往往引發難以發現的 Bug： 轉換產生暫時物件，呼叫端修改的是暫時物
Effective C# 原則 29：僅在基類強制更新導致名稱衝突時使用 new 修飾詞
new 修飾詞：隱藏繼承成員的雙面刃 new 修飾詞可在衍生類別中重新定義非虛擬繼承成員。但這會導致語意混淆：同一物件透過不同型別參考呼叫同名方法，卻執行不同程
Effective C# 第 4 章：建立二進位組件，實現獨立部署與版本控制
組件：.NET 應用程式的基本部署單位 .NET 應用程式由多個二進位組件組成，各組件可獨立更新、發行。鬆散耦合意味著減少組件間複雜依賴，輕鬆替換小塊組件。本章
Effective C# 原則 30：確保組件符合 CLS 規範，實現跨語言互通
CLS 合規性：跨語言互通的基石 .NET 運行時支援多語言開發。為讓組件被所有 .NET 語言使用，公開介面必須符合共同語言規範 (CLS)。CLS 定義所有
Effective C# 原則 31：撰寫小而簡單的函式，讓 JIT 編譯器發揮最大效能
手動優化往往適得其反 許多開發者習慣寫龐大函式以「減少呼叫開銷」，但在 .NET 中這會阻礙 JIT 編譯器最佳化，反而產生更慢代碼。最佳策略：以最清晰方式表達
