前言
良好的物件導向設計是系統可維護、可擴展的基石。本文整理自經典設計規範，精選 61 條核心原則，涵蓋封裝、耦合、內聚、繼承、多型、介面設計等核心維度，供架構師與開發者審視與重構代碼時參考。
一、 封裝與介面設計 (1-10)
- 資料隱藏：所有資料成員應為
private，僅透過公開方法存取。
- 依賴介面：使用者依賴類別的公開介面，類別不應依賴使用者。
- 最小化協議：公開介面盡量精簡，少即是多。
- 基礎公開協議：實作通用操作：複製 (深/淺)、相等比較、序列化/輸出、解析等。
- 實現細節不公開：共用私有方法不應洩露至公開介面。
- 避免無關公開成員：使用者不需要知道或不關心的東西別放入介面。
- 零耦合或導出耦合：類別之間要么無關，要么僅使用對方公開介面。
- 單一核心抽象：一個類別只代表一個關鍵抽象概念。
- 封裝變化：包內類別對同類性質變化共同封閉，對外不影響其他包。
- 相關資料行為集中：留意透過 getter 從其他物件取資料再操作的「貧血模型」違反此則。
二、 類別結構與職責 (11-20)
- 分離無關資訊：互不溝通的行為拆分至不同類別；朝穩定方向依賴。
- 抽象類別 vs 角色：建模的是類別，而非物件扮演的臨時角色；類別應統一共享工作。
- 拒絕上帝類：警惕命名含
Driver、Manager、System、Subsystem 的大類別。
- 規劃介面而非實作：設計介面優於實作介面。
- 警惕大量存取方法：公開介面若充斥 getter/setter，暗示資料行為未集中。
- 警惕過多無關行為：類別包含過多不相干方法，同樣違反內聚原則。
- 模型不依賴視圖：UI 依賴模型，模型不知 UI 存在 (MVC 核心)。
- 貼近現實建模：在不違反上述原則前提下，盡量映射現實領域。
- 移除無用類別：將其降級為屬性或移除。
- 移除系統外類別：僅向系統發訊息、不接收系統訊息的類別屬外部實體。
三、 繼承與多型設計 (21-40)
- 操作不變類別：質疑動詞命名的類別，將行為遷移至既有/新類別。
- 清理代理類：分析階段引入的代理類，設計階段若無用則移除。
- 最小化協作者數量：一個類別使用的其他類別越少越好。
- 最小化訊息傳遞：減少類別間傳遞的訊息數量與種類。
- 最小化扇出：減少「定義的訊息數 × 發送的訊息數」。
- 包含即使用：包含關係意味著使用關係，容器應向被容納物件發訊息。
- 方法使用大多數資料：類別大多數方法應使用大多數資料成員 (高內聚指標)。
- 資料成員數量 ≤ 7±2：超過 6 個考慮邏輯分組並引入組合類別。
- 窄而深的繼承體系：功能垂直分布在繼承層次中。
- 語義約束在類別層面實現：優先在類別定義 (如建構子) 強制約束；若導致類別爆炸，改在行為中實現。
- 約束測試放在最深包含層次：建構子中驗證約束時，盡量深層檢查。
- 常變語義資訊集中管理：引入第三方物件集中管理；少變則分散 在相關類別中。
- 知子不知父：類別知道包含什麼，但不知道誰包含它。
- 同層級物件不互用：共享字面作用域 (同一容器) 的物件間不應有使用關係。
- 繼承僅用於特化：
is-a 關係，非代碼復用手段。
- 子知父，父不知子：基類不應知道衍生類存在。
- 基類資料全私有：拒絕
protected 欄位，提供受保護方法供子類存取。
- 公開介面最小化：設計者永不將使用者不需要的東西放入公開介面。
- 理論上繼承越深越好：實務上深度不超過 6 (短期記憶極限)。
- 抽象類即基類，基類即抽象類：具體類不應被繼承。
- 共性上移：資料、行為、介面共性盡量上移至繼承體系高層。
四、 關係選擇與進階建模 (41-61)
- 共享資料無行為 → 組合：共同資料放入獨立類別，各類別組合它。
- 共享資料與行為 → 繼承：從公共基類繼承。
- 共享介面需多型時 → 繼承：僅當需多型對待時才建立共同基類。
- 拒絕顯式類型/屬性值判斷：以多型取代
if (type == A)；將屬性值轉為衍生類別。
- 繼承不建模動態語義：靜態繼承關係無法表達運行時類型切換，改用狀態模式/策略模式。
- 物件不變類別：單實例衍生類通常是設計錯誤，應建模為物件。
- 運行時建類別 → 建物件：若需動態建立類別，退後一步：你需要的是物件，將其概括為類別。
- 空方法覆寫非法：衍生類用空方法覆寫基類方法違反里氏替換原則。
- 可選包含 ≠ 繼承：將可選包含建模為繼承會導致類別爆炸。
- 建可復用框架，非組件：設計繼承體系時著眼於框架層面的復用。
- 多重繼承先假設犯錯：若確需，必須證明合理性。
- 繼承自檢兩問：(1) 子類是父類的特殊型別？(2) 父類是子類的一部分？
- 多重繼承檢查菱形：確保無基類實為另一基類衍生類。
- 包含優於關聯：面臨選擇時優先考慮組合/聚合。
- 全域資料/函數 → 類別變數/方法：封裝於類別內部。
- 邏輯設計優於物理設計：不讓部署/打包等物理考量破壞邏輯模型，但決策時可參考。
- 不繞過公開介面修改狀態：嚴守封裝邊界。
總結
這 61 條原則並非鐵律，而是設計審查的「檢核清單」。實務中權衡取捨，核心始終圍繞高內聚、低耦合、單一職責、介面隔離、依賴倒置 五大核心思想 (SOLID)。定期對照審視代碼，重構違反項目，方能演進出經得起時間考驗的架構。
