前言
Arthur J. Riel 曾說：「你不必嚴格遵守這些原則，違背它們也不會被處以宗教刑罰。但你應當把這些原則看成警鈴，若違背了其中的一條，那麼警鈴就會響起。」這 61 條原則涵蓋了類設計、繼承體系、耦合控制、記憶體管理等核心領域，是 PHP 開發者進階為架構師的必修課。
一、類與封裝原則（第 1-10 條）
核心思想：數據隱藏與介面隔離
- 原則 1：所有數據必須隱藏在類內部，禁止直接暴露屬性。
- 原則 2：使用者依賴公共介面，類不應依賴使用者（依賴倒置雛形）。
- 原則 3：盡量減少類協議中的訊息數量，保持介面精簡。
- 原則 4：實現基礎公共介面（如深/淺拷貝、相等性判斷、序列化）。
- 原則 5：私有輔助方法不應出現在公共介面中；共用代碼應提煉為私有函數。
- 原則 6：公共介面不得包含使用者無法使用或不關心的內容。
- 原則 7：類之間應為零耦合或僅透過導出耦合（僅使用公共操作）關聯。
- 原則 8：每個類只代表一個關鍵抽象（單一職責前身）。
- 原則 9：相關數據與行為必須集中放置；警惕頻繁呼叫 getter 的「貧血模型」。
- 原則 10：不相關的資訊應分離到不同類中；依賴關係應指向穩定方向。
二、系統結構與職責分配（第 11-20 條）
避免上帝類，職責均勻分佈
- 原則 11：建模的抽象必須是類，而非物件扮演的角色。
- 原則 12：水平方向統一分佈系統功能，頂層類共享工作。
- 原則 13：嚴防「全能類」（命名含 Driver、Manager、System、Subsystem 需警惕）；規劃介面而非實作介面。
- 原則 14：大量存取方法（get/set）暗示數據與行為未集中。
- 原則 15：類包含過多互不溝通行為同屬違規。
- 原則 16：模型不應依賴 UI，UI 應依賴模型（MVC 核心）。
- 原則 17：盡可能按現實世界建模（但為遵守其他原則常需妥協）。
- 原則 18：移除不必要的類，通常降級為屬性。
- 原則 19：移除系統外部類（僅發送訊息不接收）。
- 原則 20：不要將操作變成類；質疑動詞命名的單一行為類。
三、協作與耦合控制（第 21-28 條）
降低協作者數量、訊息傳遞與扇出
- 原則 21：設計階段移除無用的代理類。
- 原則 22：最小化類的協作者數量。
- 原則 23：最小化類與協作者間的訊息傳遞總數。
- 原則 24：最小化協作類型（不同訊息數）。
- 原則 25：最小化扇出（定義訊息數 × 發送訊息數）。
- 原則 26：包含關係必須意味著使用關係（包含者發送訊息給被包含者）。
- 原則 27：大多數方法應在大多數時間使用大多數數據成員（內聚度指標）。
- 原則 28：類包含的物件數不超過短期記憶容量（建議 ≤6）；超過時以包含類分組。
四、繼承體系設計（第 29-58 條）
特化層次、語義約束與多型應用
- 原則 29：系統功能在窄而深的繼承體系中垂直分佈。
- 原則 30-33：語義約束實作策略：優先在類定義/建構子中實作；常變資訊集中於第三方物件，少變資訊分散在相關類中。
- 原則 34：類必須知道它包含什麼，但不能知道誰包含它（單向知曉）。
- 原則 35：同一作用域（同一個類包含）的物件間不應有使用關係。
- 原則 36：繼承僅用於建模特化層次（is-a 關係）。
- 原則 37：派生類知曉基類，基類不知派生類。
- 原則 38：基類數據全私有，拒絕 protected；公共介面不放使用者不需要的東西。
- 原則 39-40：理論上繼承越深越好，實踐中深度不超過 6（短期記憶限制）。
- 原則 41-42：所有抽象類皆為基類，所有基類皆應為抽象類。
- 原則 43：共性數據、行為、介面上移至繼承體系高端。
- 原則 44：共享數據無共享行為 → 組合（包含共同數據類）。
- 原則 45：共享數據與行為 → 繼承共同基類。
- 原則 46：共享介面（訊息）僅在需多型使用時才繼承共同基類。
- 原則 47：顯式物件類型 case 分析通常錯誤 → 使用多型。
- 原則 48：顯式屬性值 case 分析通常錯誤 → 解耦為繼承層次，屬性值轉為派生類。
- 原則 49：勿用靜態繼承建模動態語義（會導致運行時切換類型）。
- 原則 50：勿將物件變為派生類；警惕單實例派生類。
- 原則 51：需運行時創建類時，退回思考：你需要的是物件，將其概括為類。
- 原則 52：派生類以空方法覆寫基類方法應視為非法（違反里氏替換）。
- 原則 53：勿混淆可選包含與繼承需求（會導致類爆炸）。
- 原則 54：創建可復用框架而非可復用組件。
- 原則 55：使用多重繼承先假設犯錯，需證明合理性。
- 原則 56：使用繼承時自問：(1) 派生類是基類的特殊型別？(2) 基類是派生類的部分？
- 原則 57：多重繼承中確保無基類實為另一基類的派生類。
- 原則 58：包含關係優於關聯關係。
五、其他關鍵準則（第 59-61 條）
- 原則 59：勿用全域變數/函數做物件簿記 → 改用類變數/類方法。
- 原則 60：邏輯設計不應被物理設計破壞，但決策過程可參考物理準則。
- 原則 61：嚴禁繞過公共介面修改物件狀態。
總結
這 61 條原則並非僵化教條，而是設計品質的「警鈴」。實務中應根據專案規模、團隊熟悉度靈活取捨，核心目標始終是：高內聚、低耦合、清晰職責、可維護擴展。建議將其作為 Code Review 清單，定期檢視專案架構健康度。
