PHP面向对象设计模式
?
PHP設計模式——概述
?
?
常見的面向對象設計模式大約有23種，但是自從接觸PHP后，漸漸發現常見的設計模式好像少了很多，網絡上的資料也比較少，身邊的PHP同事們有的甚至沒有聽說過設計模式，這也有可能是PHP的發展所帶來的，因為PHP對面向對象支持的比較晚，好多PHP程序員還按照面向過程的思想寫代碼。于是，我決定把原來用C#寫的面向對象設計模式用PHP改寫。
??????
??????? 經常聽見其他程序員(Java、 C#)等說PHP是不是運行在瀏覽器端的腳本語言，其實我在接觸PHP之前也這樣認為過，后來發現PHP是用C語言開發出來的一種語言，C語言是真正意義 上跨平臺的語言，這也注定PHP是跨平臺的，PHP是可運行在Windows Server或Linux操作系統的服務器上的語言，它和Java以及C#一樣，代碼存儲并運行在服務器端，它將瀏覽器端可執行的HTML以及腳本發送給 瀏覽器執行，PHP相對Java和C#對于面向過程的封裝更多，減少部分數據類型的支持。
??????? PHP是面向對象的，PHP能夠得到這樣快速的發展，能夠被互聯網大企業所廣泛應用，證明PHP是經得住考驗的，隨著移動互聯網的不斷發展，PHP還會更廣闊的天地。
??
????? 什么是設計模式？
?????? 設計模式（Design Pattern）是一套被反復使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結。使用設計模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。設計模式于己于他人于系統都是多贏的；設計模式使代碼編制真正工程化；設計模式是軟件工程的基石脈絡，如同大廈的結構一樣。?????
??????? 項目中合理的運用設計模式可以完美的解決很多問題，每種模式在現在中都有相應的原理來與之對應，每一個模式描述了一個在我們周圍不斷重復發生的問題，以及該問題的核心解決方案，這也是它能被廣泛應用的原因。
?????? 設計模式的優點：
??????? 1).復用解決方案: 設計模式本身就是對某一類問題的通用解決方案，是更高級別的復用，已經超出了代碼復用.??????? 2).確定通用術語:開發中的交流和協作都需要共同的詞匯其礎和對問題的共識. 當你有想表達卻又表達不清楚的設計思路，即使表達出來也會被同事誤解的時候，設計模式就顯出溝通的優勢了。
??????? 3).代碼更易于修改與維護。因為設計模式都是久經考驗的解決方案,它們的結構都是經過長期的發展形成的，善于應對變化，設計模式本身也是對變化點的封裝。
??????? 4).模式有助于提高思考層次。學習模式后,就算不用模式中的方法，也會更好的采取更好的策略去解決問題。
??????? 在接下來的篇幅里會詳細介紹PHP面向對象設計模式，本系列博客以設計模式的原理為核心，列舉最簡單的例子，讓只要有一點面向對象基礎的讀者都能看明白。
?
?
PHP設計模式——六大原則
?
?????一般認為遵從以下六大原則的代碼是易擴展可復用的代碼：
?
??? ? ? ? ? ? ? ? ? ? ? ???
?
?????
?
?????這六大原則任何面向對象的語言都應該遵守的，要想讓你的代碼易擴展高服用就盡量去滿足這六大原則吧，不一定嚴格按照某種設計模式，但是如果你的代碼符合這六大原則，那么你的代碼就是好代碼了，好的代碼不一定是嚴格按照設計模式寫的代碼。
?
?
???????? 1.單一職責
?
????????定義：不要存在多于一個導致類變更的原因。通俗的說，即一個類只負責一項職責。
?
???????? 場景：類T負責兩個不同的職責：職責P1，職責P2。當由于職責P1需求發生改變而需要修改類T時，有可能會導致原本運行正常的職責P2功能發生故障，關系如下圖：
?
????????????????????????????????????????????????????????????????????????????????????????????
?
?
??????? 修改：遵循單一職責原則。分別建立兩個類T1、T2，使T1完成職責P1功能，T2完成職責P2功能。這樣，當修改類T1時，不會使職責P2發生故障風險；同理，當修改T2時，也不會使職責P1發生故障風險，結構如下圖：
?
??? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
?
????? 優點：
?
??????????? 1）、可以降低類的復雜度，一個類只負責一項職責，邏輯簡單；
?
???????????? 2）、提高類的可讀性，提高系統的可維護性；
?
???????????? 3）、變更引起的風險降低，變更是必然的。
????
????2.里氏代換原則
?
???? 定義：所有引用基類的地方必須能透明地使用其子類的對象，也就是說子類可以擴展父類的功能，但不能改變父類原有的功能
?
?????場景：有一功能P1，由類A完成。現需要將功能P1進行擴展，擴展后的功能為P，其中P由原有功能P1與新功能P2組成。新功能P由類A的子類B來完成，則子類B在完成新功能P2的同時，有可能會導致原有功能P1發生故障，如下圖：
?
?
???????????????????????????????????? ??
?
??????? CountPriceByJKL類繼承于CountPrice類，CountPriceByJKL重寫了Count()方法，這樣可能影響到原來Count方法的功能。
?
?
??????? 修改：當使用繼承時，遵循里氏替換原則。類B繼承類A時，除添加新的方法完成新增功能P2外，盡量不要重寫父類A的方法，也盡量不要重載父類A的方法。
?
?
??????? 3.依賴倒置原則
?
??????? 定義：高層模塊不應該依賴低層模塊，二者都應該依賴其抽象；抽象不應該依賴細節；細節應該依賴抽象。
?
??????? 此處理解起來是最困難的，一般會在項目框架的搭建的時候用到，例如，業務邏輯層相對于數據層是高層模塊，因為業務邏輯層需要調用數據層去連接數據庫，但是要做到可擴展高復用，盡量不要讓業務邏輯層依賴數據層，可以在數據層抽象出一個接口，讓業務邏輯層依賴于這個抽象接口。
?
???????? 場景：類A（高層模塊）直接依賴類B（低層模塊），假如要將類A改為依賴類C（低層模塊），則必須通過修改類A的代碼來達成。這種場景下，類A一般是高層模塊，負責復雜的業務邏輯；類B和類C是低層模塊，負責基本的原子操作；假如修改類A，會給程序帶來不必要的風險。
?
?????????????????????????????????????????????????????????????
?
??????????AutoSystem類直接依賴于HondaCar與FordCar兩個類，這樣就產生了一個高耦合，AutoSystem類想操控HondaCar或者FordCar必須直接創建相應對象。
?
???????? 修改：將類A修改為依賴接口I，類B和類C各自實現接口I，類A通過接口I間接與類B或者類C發生聯系，則會大大降低修改類A的幾率，如下圖：
?
?????? ? ? ? ? ? ? ? ? ???
?
?????????? 經過此番修改，Honda與Ford實現ICar接口，提供了Run、Stop以及Turn功能方法，AutoSystem依賴ICar接口，這樣迫使AutoSystem依賴抽象接口，這就使得AutoSystem類能夠應對更多的需求變化。
?
?
????????? 優點：
?
??????????????? 1）、低層模塊盡量都要有抽象類或接口，或者兩者都有。
?
???????????????? 2）、變量的聲明類型盡量是抽象類或接口。
?
???????????????? 3）、使用繼承時遵循里氏替換原則。
?
?????????? 4.接口隔離原則
?
?????????? 定義：客戶端不應該依賴它不需要的接口；一個類對另一個類的依賴應該建立在最小的接口上。
?
?
?????????? 場景：類A通過接口I依賴類B，類C通過接口I依賴類D，如果接口I對于類A和類B來說不是最小接口，則類B和類D必須去實現他們不需要的方法，如下圖：
?
?
?
?
修改：將臃腫的接口I拆分為獨立的幾個接口，類A和類C分別與他們需要的接口建立依賴關系。也就是采用接口隔離原則。
?
?
?
注意：
?
?
?
1）、接口盡量小，但是要有限度。對接口進行細化可以提高程序設計靈活性???是不掙的事實，但是如果過小，則會造成接口數量過多，使設計復雜化。所以一定要適度。
?
?? 2）、為依賴接口的類定制服務，只暴露給調用的類它需要的方法，它不需要的方法則隱藏起來。只有專注地為一個模塊提供定制服務，才能建立最小的依賴關系。
?? 3）、提高內聚，減少對外交互。使接口用最少的方法去完成最多的事情。
?
? ５.迪米特法則（最少知道原則）
?
定義：一個對象應該對其他對象保持最少的了解。
?
場景：類與類之間的關系越密切，耦合度越大，當一個類發生改變時，對另一個類的影響也越大。
?
簡單的理解就是高內聚，一個類盡量減少對其他對象的依賴，并且這個類的方法和屬性能用私有的就盡量私有化。
?
?
注意：
?
??????????? 1）、只與直接的朋友通信，不要和陌生人說話。
?
??????????? 2）、過分的使用該原則，將導致系統復雜度變大。所以在采用迪米特法則時要反復權衡，既做到結構清晰，又要高內聚低耦合。
?
?
??????? 6.開閉原則
?
??????? 定義：一個軟件實體如類、模塊和函數應該對擴展開放，對修改關閉。
?
??????? 場景：在軟件的生命周期內，因為變化、升級和維護等原因需要對軟件原有代碼進行修改時，可能會給舊代碼中引入錯誤，也可能會使我們不得不對整個功能進行重構，并且需要原有代碼經過重新測試。
?
?????? 建議：當軟件需求變化時，盡量通過擴展軟件實體的行為來實現變化，而不是通過修改已有的代碼來實現變化。
?
?
?
PHP設計模式——簡單工廠
前面兩節內容介紹了什么是設計模式以及六大原則，相信看完前兩節內容大家對設計模式已經有了初步的認識，接下來說一下設計模式的分類。
??????? 一般將面向對象設計模式分為三類：創建型、結構型、行為型三種。
??????? 創建型：創建對象時，不再由我們直接實例化對象；而是根據特定場景，由程序來確定創建對象的方式，從而保證更大的性能、更好的架構優勢。創建型模式主要有簡單工廠模式（并不是23種設計模式之一）、工廠方法、抽象工廠模式、單例模式、生成器模式、原型模式。
?????? 結構型：用于幫助將多個對象組織成更大的結構。結構型模式主要有適配器模式、橋接模式、組合器模式、裝飾器模式、門面模式、亨元模式和代理模式。
?????? 行為型：用于幫助系統間各對象的通信，以及如何控制復雜系統中流程。行為型模式主要有命令模式、解釋器模式、迭代器模式、中介者模式、備忘錄模式、觀察者模式、狀態模式、策略模式、模板模式、訪問者模式和職責鏈模式。
???????? ?
?????? 今天主要介紹創建型的第一種簡單工廠模式。
?????? 注意：在閱讀本系列博客的時候一定要有閱讀UML類圖、面向對象PHP編程基礎。
??????
?????? 簡單工廠模式不屬于23種常用面向對象設計模式之一。簡單工廠模式是由一個工廠對象決定創建出哪一種產品類的實例。簡單工廠模式是工廠模式家族中最簡單實用的模式，可以理解為是不同工廠模式的一個特殊實現。其實質是由一個工廠類根據傳入的參數，動態決定應該創建哪一個產品類（這些產品類繼承自一個父類或接口）的實例。
????????????????????????????????????
?????? 角色及職責：??
?????? 工廠（SimpleFactory）角色：簡單工廠模式的核心，它負責實現創建所有實例的內部邏輯。工廠類可以被外界直接調用，創建所需的產品對象。
?????? 抽象產品（IProduct）角色：簡單工廠模式所創建的所有對象的父類，它負責描述所有實例所共有的公共接口。
?????? 具體產品（Concrete Product）角色：是簡單工廠模式的創建目標，所有創建的對象都是充當這個角色的某個具體類的實例。
????? 需求：根據提供相應的屬性值由簡單工廠創建具有相應特性的產品對象。
????? 現根據以上UML類圖編寫如下PHP代碼。
?????
[php] view plaincopy print?
???????? 測試代碼：
????? 用瀏覽器訪問測試代碼，我們可以發現創建的對象依次是YProduct,XProduct,XYProduct,null。簡單工廠的核心代碼在于工廠 (ProductFactory)這個角色，這里根據傳入的xMax與yMax值去創建不同的對象，這便是簡單工廠的實質，而且我們在測試調用客戶端根本 不知道具體的產品類是什么樣，這樣就做到了調用與創建的分離。
?????? 簡單工廠的優點：讓對象的調用者和對象創建過程分離，當對象調用者需要對象時，直接向工廠請求即可。從而避免了對象的調用者與對象的實現類以硬編碼方式耦合，以提高系統的可維護性、可擴展性。
?????? 簡單工廠的缺點：當產品修改時，工廠類也要做相應的修改，比如要增加一種操作類，如求M數的N次方，就得改case,修改原有類，違背了開放-封閉原則。
????????? 更多詳情敬請關注我的視頻課程：
?
?
?
轉載于:https://www.cnblogs.com/aipiaoborensheng/p/5730570.html
總結
以上是生活随笔為你收集整理的PHP面向对象设计模式的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 面向对象编程之：封装、继承、多态
- 下一篇： php+nginx环境配置注意事项