C# 物件導向設計七大核心原則深度解析

在 C# 物件導向開發中，掌握設計原則是編寫可維護、可擴展程式碼的關鍵。本文系統整理了七大核心原則，包含單一職責、開放封閉、里氏替換、介面隔離、依賴反轉、迪米特法則與合成復用，並透過實務場景說明其應用價值。

1. 開放封閉原則（Open-Closed Principle, OCP）

核心定義

軟體實體（模組、類別、函式）應對擴充開放，對修改關閉。意即在不異動既有程式碼的前提下，透過擴充方式新增功能。

產生背景

軟體生命週期中，因需求變更而直接修改舊碼，極易引入錯誤、觸發連鎖重構，並大幅增加測試成本。高耦合是根本禍首，解耦合才是面向物件開發的核心任務。

解決策略

善用抽象類別與介面建構框架，具體實作留給衍生類別。需求變動時，撰寫新類別實作介面，而非修改現有邏輯。

實務啟示

OCP 具理想主義色彩，是物件導向設計的終極目標；其餘六大原則可視為落實 OCP 的具體手法。

2. 單一職責原則（Single Responsibility Principle, SRP）

核心定義

一個類別應只有一個引起它變更的原因，亦即只負責單一職責。

違反後果

多重職責耦合在同一類別，任一職責變更皆可能波及其他功能，導致設計脆弱、復用性低落。典型案例為邏輯與介面混雜。

重構做法

將不同職責拆分為獨立類別（如 T1 負責 P1、T2 負責 P2），修改時互不干擾。此原則不限於 OOP，模組化程式設計皆適用。

3. 里氏替換原則（Liskov Substitution Principle, LSP）

核心定義

子類型必須能替換其父類型，且不影響程式正確性。通俗稱「老鼠的兒子會打洞」。

違反情境

子類別覆寫父類別非抽象方法、強化前置條件或削弱後置條件，導致原有功能失效。

遵循準則

• 子類別可新增方法、實作抽象方法，但不可覆寫父類別非抽象方法。
• 覆寫時，輸入參數（前置條件）應比父類別更寬鬆，回傳值（後置條件）應比父類別更嚴格。

核心精神

所有引用父類別的地方，必須透明地使用子類別物件；子類別只能擴充功能，不能改變既有行為。

4. 迪米特法則（Law of Demeter, LoD）

核心定義

又稱最少知識原則：物件應盡量少了解其他物件。非直接朋友（非成員變數、方法參數、回傳值中的類別）不應出現在局部變數中。

耦合與複雜度的平衡

降低耦合確能提升復用率，但過度套用會產生大量「中介類別」，反而增加系統複雜度。實務上需在結構清晰與高內聚低耦合間取得平衡。

5. 依賴反轉原則（Dependency Inversion Principle, DIP）

核心定義

高層模組不應依賴低層模組，二者皆應依賴抽象；抽象不依賴細節，細節依賴抽象。核心即面向介面程式設計。

實作三要素

1. 低層模組皆提供抽象類別或介面。
2. 變數宣告型別盡量用抽象類別或介面。
3. 繼承時遵循里氏替換原則。

團隊協作價值

專案規模越大、協作人數越多，DIP 的價值越顯著，能有效隔離變更風險。

6. 介面隔離原則（Interface Segregation Principle, ISP）

核心定義

客戶端不應依賴它不需要的介面；依賴關係應建立在最小介面上。

違反現象

臃腫介面強迫實作類別實現不需的方法（如圖示中紅字標註），違反單一職責且增加維護負擔。

拆分策略

• 使用委派分離介面
• 使用多重繼承分離介面
• 將大介面拆解為多個專用小介面，客戶端按需依賴

適度原則

介面過大或過小皆非良策。過小會導致介面爆炸、設計複雜化；需投入思考時間，依業務邊界精準切分。

7. 合成/聚合復用原則（Composite/Aggregate Reuse Principle, CARP）

核心主張

優先使用合成/聚合（Has-a），盡量避免類別繼承。

繼承的三大侷限

1. 編譯期靜態綁定，無法執行期動態切換實作。
2. 子類別與父類別高度耦合，父類別任何變動必波及子類別。
3. 繼承來的實作若不適用新問題，父類別被迫修改或替換，嚴重限制彈性與復用性。

總結

設計模式正是這七大原則的具體實踐。深入研讀設計模式，能幫助開發者內化原則，寫出真正具備擴充性與復用性的優質程式碼。