友情連結：
1.一看就懂系列之 php設計模式(一)
2.一看就懂系列之php設計模式(二)
前言
這篇文章是我寫完三種設計模式之後才寫的，究其原因呢，是由於今天get到了一些更為設計模式原則的東西，不管是設計模式還是大家平常寫的程式碼，都會無意間用到何遵守的，我打算用自己的話來寫一遍。
你不知道的設計模式原則
定義
不要存在多於一個導致類變更的原因。通俗的說，即一個類只負責一項職責。
白話文理解
能分工協作的盡量分好工，各自負責自己的一塊，並且把它做好就好了，避免相互影響。
定義
所有引用基類的地方必須能透明地使用其子類的對象，也就是說子類可以擴展父類的功能，但不能改變父類原有的功能
白話文理解
當要繼承前人寫的類別的時候，盡量不重寫和重載裡面的方法，因為你根本不知道，哪裡會被影響。繼承方法也盡量尊重原邏輯不輕易改變。
定義
高層模組不應該依賴低層模組，二者都應該依賴其抽象；抽像不應該依賴細節；細節應該依賴抽象。
白話文理解
父親模組不和其子模組相互依賴，最好都依賴第三方（抽象的類）,可以避免高耦合的坑，萬一產品改策略，也可以輕鬆通過橫向擴展（再來一個繼承抽象類別的子類別）來解決，繼承的話遵循里氏代換原則
定義
客戶端不應該依賴它不需要的介面；一個類別對另一個類別的依賴應該建立在最小的介面上。
白話文理解
如果是透過介面進行程式設計的，不要將一堆抽象的方法放在介面類別中，這樣會造成繼承的類別還要去實作根本不屬於它的方法，即使是接口，也盡量依照總分的概念去勾劃，共用的寫在一個介面類別中，個別客製化的應單獨寫，子類別選擇性繼承介面類別就好。
定義
一個物件應該對其他物件保持最少的了解。
白話文理解
典型的知道了太多更容易死的道理，放在代碼裡就是，寫一個模組的時候盡量能分就分，一個模組包含越多耦合越大，越容易出錯，拆成各自獨立模組，即使出問題也不會全崩。
定義
一個軟體實體如類、模組和函數應該對擴充開放，對修改關閉。
白話文理解
當產品需求變化時，盡量透過擴展軟體實體的行為來實現變化（加類，加上方法），而不是透過修改現有的程式碼來實現變化。
一個問題的討論
<code>很多优化的地方都在说：高内聚低耦合，那么问题来了，高内聚低耦合真的好吗？</code>
我的看法是：看業務的具體邏輯，因為高內聚低耦合的話，一旦某一塊業務相互關聯又比較複雜，會直接導致很多獨立的代碼塊存在，即使有備註，看起程式碼會給人一種跳來跳去的感覺，閱讀性會降低，直接導致維護性會降低，當程式碼接手給別人時候，後人將在理解程式碼方面花費很多時候，寸步難行。聽說適當的耦合代碼和具體依賴關係分塊更配哦～
單純的依照前人總結的抽象的規範寫程式也是不對的，好的設計模式是一步一步改出來的，而不是一開始就設計好的。
').addClass('pre-numbering').hide(); $(this).addClass('has-numbering').parent().append($numbering); for (i = 1; i ').text(i)); }; $numbering.fadeIn(1700); }); });歡迎留言分享
以上就介紹了一看就懂系列之 php設計模式零，包括了方面的內容，希望對PHP教程有興趣的朋友有所幫助。
