Arthur J. Riel 曾說：「你不必嚴格遵守這些原則，違背它們也不會被處以宗教刑罰。但你應當把這些原則看成警鈴，若違背了其中的一條，那麼警鈴就會響起。」這 25 條原則源自物件導向設計的經典智慧，專為 PHP 開發者整理，旨在幫助你構建更易維護、可擴展、低耦合的系統。
原則 (1)：所有資料都應隱藏在類別內部，透過公開介面存取，防止外部直接操作內部狀態。
原則 (5)：不要將實作細節（如共用私有函式）暴露於公有介面。若兩個方法有共同代碼，應提煉為私有函式。
原則 (6)：公開介面不應包含使用者無法使用或不感興趣的內容，保持介面精簡。
原則 (2)：使用者依賴類別的公開介面，類別不應依賴使用者，實現單向依賴。
原則 (7)：類別之間應零耦合，或僅有導出耦合（僅使用對方公開介面）。
原則 (11)：確保建模的抽象概念是類別，而非物件扮演的角色。
原則 (16)：在由使用者介面互動的模型中，模型不應依賴介面，介面應依賴模型。
原則 (8)：類別應只代表一個關鍵抽象。
原則 (9)：相關資料與行為應集中放置。若物件頻繁透過 getter 從其他物件取得資料，暗示違反此原則。
原則 (10)：不相關的資訊應放在另一個類別中（互不溝通的行為）。
原則 (13)：規劃介面而非實作介面；避免創建全能類別（名稱含 Driver、Manager、System、Subsystem 者需特別小心）。
原則 (14)：警惕定義大量存取方法的類別，通常意味著資料與行為未集中。
原則 (15)：警惕包含太多互不溝通行為的類別，常表現為大量 getter/setter。
朝向穩定方向依賴：依賴關係應指向較穩定、較不易變動的抽象。
原則 (12)：水平統一分佈系統功能，頂層類別應統一共享工作。
原則 (17)：盡可能依現實世界建模，但為遵守功能分佈、避免全能類別、集中相關資料行為，有時需妥協。
原則 (18)：移除不必要的類別，通常將其降級為屬性。
原則 (19)：移除系統外的類別（僅向系統發送訊息、不接收訊息的類別）。
原則 (20)：不要將操作變成類別。質疑名稱為動詞或源自動詞的類別，特別是僅有一個有意義行為的類別。
原則 (21)：分析模型中引入的代理類別，在設計階段若發現無用應移除。
原則 (22)：減少類別的協作者數量（使用的其他類別數）。
原則 (23)：減少類別與協作者間傳遞的訊息數量。
原則 (24)：減少協作量（不同訊息的數量）。
原則 (25)：減少類別的扇出（定義的訊息數與發送的訊息數的乘積）。
這些原則並非鐵律，而是設計時的檢核清單。定期審視代碼，聆聽「警鈴」響起的時刻，勇於重構，才能讓 PHP 專案長期保持健康演進。
