如果類之間有非常強的依賴性，那麼這樣的系統就很難維護，因為系統裡的乙個改動會引起一連串的相關改動。
重用性是物件導向設計的主要目的，而緊耦合便是它的敵人。當我們看到系統中乙個元件的改變迫使系統其他許多地方也發生改變的時候，就可以診斷為緊耦合了。
在你自己的專案中，你會看到很多這種需要分離元件的情況。例如，課程系統應包含註冊元件，從而向系統新增新課程。新增新課程後，應該通知管理員，這是註冊程式的一部分。
下面的這些**對使用通知程式的系統隱藏了通知程式的實現細節：
我們了解到可以把不同的實現隱藏在父類所定義的共同介面下，然後客戶端**需要乙個父類的物件而不是乙個子類的物件，從而使客戶端**可以不用關心它實際得到的是哪個具體實現。從客戶端**來看，類方法引數為抽象或通用型別通常是不錯的主意。如果引數對物件型別要求過於嚴格，就會限制**在執行時的靈活性。
當然，如何使用引數型別提示來調整引數物件的「通用性」是需要仔細權衡的。選中過於通用，則會降低方法的安全性。而如果是某個子型別的特有功能，那麼方法接受另乙個子類型別則可能會有風險。
一旦做出設計決定，解釋它就很容易。但是你如何決定從**開始設計呢？
「把變化的概念封裝起來」。在我們的示例中，「變化的概念」就是費用計算。我們發現為這個變化直接建立子類是不合適的，於是使用了條件語句。通過把變化的元素放入同乙個類中，我們強調了封裝的適用性。
《設計模式》建議積極搜尋類中變化的元素，並評估它們是否適合用新型別來封裝。根據一定條件，變化的元素可被提取出來形成子類，而這些元素共同擁有乙個抽象父類。而這個新型別能被其他類使用。這麼做有以下好處：
那麼如何發現變化的元素呢？誤用繼承便是乙個標誌，當然適合封裝「變化元素」的另乙個標誌便是出現了條件表示式。
模式的乙個問題便是不必要或不恰當地使用模式。
「極限程式設計」提供了幾個可以使用的相關原則。第乙個是「你還不需要它」，第二個是「用最簡單的方式來完成任務」。
以《設計模式》為起點，將模式分為以下幾種：
深入PHP物件導向 模式與實踐 設計模式
設計模式便是分析過的問題和問題解決方案所闡釋的優秀實踐。如何處理乙個請求？如何將請求資料轉換成系統對應的指令？如何獲得資料？如何顯示結果？等等。隨著時間流逝和經驗積累，我們會或優雅或困難地回答問題，並總結出一些非正式的 可在專案中重複使用的解決方案，而這些解決方案便是設計模式。設計模式記錄並規範了這...
深入PHP物件導向 模式與實踐 模式原則（1）
通過以靈活的方式來組合物件，元件能在執行時被定義。設計模式 將此提煉出乙個原則 組合優於繼承。繼承是應對變化的環境及上下文設計的有效方式，然而它會限制靈活性，尤其是當類承擔了過多的責任的時候。利用這種繼承模式，我們可以在課程的實現之間切換。可是如果引入一組新的特殊性，又會怎麼樣？比如我們需要處理演講...
深入PHP物件導向 模式與實踐 企業模式（3）
前端控制器模式用乙個中心來處理所有到來的請求，最後呼叫檢視來將結果呈現給使用者。前端控制器模式定義了乙個中心入口，每個請求都要從這個入口進入系統。前端控制器處理請求並選擇要執行的操作。系統中的控制器複製分配任務給其他。其他類完成了絕大部分實際工作。前端控制器通常通過執行乙個command物件來呼叫應...