本文例項講述了PHP設計模式。分享給大家供大家參考，具體如下：

1. 設計模式

設計模式（Design pattern）是一套被反覆使用、多數人知曉的、經過分類編目的、程式碼設計經驗的總結。使用設計模式是為了可重用程式碼、讓程式碼更容易被他人理解、保證程式碼可靠性。 毫無疑問，設計模式於己於他人於系統都是多贏的，設計模式使程式碼編制真正工程化，設計模式是軟體工程的基石，如同大廈的一塊塊磚石一樣。
模式的經典定義：每個模式都描述了一個在我們的環境中不斷出現的問題，然後描述了該問題的解決方案的核心，通過這種方式，我們可以無數次地重用那些已有的解決方案，無需再重複相同的工作。即模式是在特定環境中解決問題的一種方案

2. 設計模式 目的

其目的就是一方面教你如何利用真實可靠的設計來組織程式碼的模板。 簡單地說，就是從前輩們在程式設計過程中總結、抽象出來的通用優秀經驗。主要目的一方面是為了增加程式的靈活性、可重用性。 另一方面也有助於程式設計的標準化和提高系統開發進度。

也有人忠告：不要過於注重程式的“設計模式”。 有時候，寫一個簡單的演算法，要比引入某種模式更容易。在多數情況下，程式程式碼應是簡單易懂，甚至清潔工也能看懂。不過呢在大專案或者框架中，沒有設計模式來組織程式碼，別人是不易理解的。

一個軟體設計模型也僅僅只是一個引導。它必須根據程式設計語言和你的應用程式的特點和要求而特別的設計。

3. 設計模式歷史

設計模式”這個術語最初被設計用於建築學領域。Christopher Alexander 在他1977的著作“A Pattern Language :Towns/Building/Construction”裡面描述了一些常見的建築學設計問題，並解釋瞭如何用這些已有的，著名的模式集合來開始全新 的有效的設計。Alexander的觀點被很好的轉化到軟體開發上來，並且長期的合意的用原有的元件來構造新的解決方案。

4. 設計模式的四個基本要素

設計模式使人們可以更加簡單方便地複用成功的設計和體系結構。將已證實的技術表述成設計模式也會使新系統開發者更加容易理解其設計思路。

所有的設計模式都有一些常用的特性：一個標識

模式名稱（pattern name）： 描述模式的問題、解決方案和效果

一個設計模式的標識（模式名稱）是重要的，因為它會讓其他的程式設計師不用進行太深入的學習就能立刻理解你的程式碼的目的（至少通過這個標識程式設計師會很熟悉這個模式）。沒有這個模式名，我們便無法與其他人交流設計思想及設計結果。

問題(problem) ：描述是用來說明這個模式的應用的領域。

描述了應該在何時使用模式。它解釋了設計問題和問題存在的前因後果，它可能描述了特定的設計問題，如怎樣用物件表示演算法等。也可能描述了導致不靈活設計的類或物件結構。有時候，問題部分會包括使用模式必須滿足的一系列先決條件。

解決方案(solution) ： 描述了這個模型的執行。
描述了設計的組成成分，它們之間的相互關係及各自的職責和協作方式。因為模式就像一個模板，可應用於多種不同場合，所以解決方案並不描述一個特定而具體的設計或實現，而是提供設計問題的抽象描述和怎樣用一個具有一般意義的元素組合（類或物件組合）來解決這個問題。

效果(consequences)

描述了模式應用的效果及使用模式應權衡的問題。儘管我們描述設計決策時，並不總提到模式效果，但它們對於評價設計選擇和理解使用模式的代價及好處具有重要意義。軟體效果大多關注對時間和空間的衡量，它們也表述了語言和實現問題。因為複用是面向物件設計的要素之一，所以模式效果包括它對系統的靈活性、擴充性或可移植性的影響，顯式地列出這些效果對理解和評價這些模式很有幫助。一個好的設計模式的論述應該覆蓋使用這個模型的優點和缺點。

一個模式是解決特定問題的有效方法。一個設計模式不是一個庫（能在你的專案中直接包含和使用的程式碼庫）而是一個用來組織你的程式碼的模板（Java bean）。事實上，一個程式碼庫和一個設計模式在應用上是有很多不同的。

比如，你從店鋪裡面買的一件襯衫是一個程式碼庫，它的顏色，樣式和大小都由設計師和廠商決定，但它滿足了你的需求。 然而，如果店裡面沒有什麼衣服適合你，那你就能自己建立自己的襯衫（設計它的形狀，選擇布料，然後裁縫在一起）。但是如果你不是一個裁縫，你可能會發現自 己很容易的去找一個合適的模式然後按著這個模式去設計自己的襯衫。使用一個模型，你可以在更少的時間內得到一個熟練設計的襯衫。

回到討論軟體上來，一個數據提取層或者一個CMS（content management system）就是一個庫——它是先前設計好而且已經編碼好了的，如果它能準確的滿足你的需要那它就是一個好的選擇。但如果你正在讀這本書《設計模式》，可能你會發現 庫存的（原有的）解決方案並不是總是對你有效。至今你知道什麼是你所要的，而且你能夠實現它，你僅僅需要一個模型來引導你。

最後一個想法：就象一個裁縫模型，一個設計本身而言是沒有什麼用處的。畢竟，你不可能穿一個服裝模型——它僅僅是由很薄的紙拼湊起來的。類似的，一個軟體設計模型也僅僅只是一個引導。它必須根據程式設計語言和你的應用程式的特點和要求而特別的設計。

3. 設計模式分類

1）根據其目的（模式是用來做什麼的）可分為建立型(Creational)，結構型(Structural)和行為型(Behavioral)三種：
• 建立型模式主要用於建立物件。
• 結構型模式主要用於處理類或物件的組合。
• 行為型模式主要用於描述對類或物件怎樣互動和怎樣分配職責。

2）根據範圍，即模式主要是用於處理類之間關係還是處理物件之間的關係，可分為類模式和物件模式兩種：

• 類模式： 處理類和子類之間的關係，這些關係通過繼承建立，在編譯時刻就被確定下來，是屬於靜態的。
• 物件模式：處理物件間的關係，這些關係在執行時刻變化，更具動態性。

4. 一些基本的設計模式 （百度百科）

Abstract Factory（抽象工廠模式）：提供一個建立一系列相關或相互依賴物件的介面，而無需指定它們具體的類。 　　

Adapter（介面卡模式）：將一個類的介面轉換成客戶希望的另外一個介面。A d a p t e r模式使得原本由於介面不相容而不能一起工作的那些類可以一起工作。

Bridge（橋接模式）：將抽象部分與它的實現部分分離，使它們都可以獨立地變化。

Builder（建造者模式）：將一個複雜物件的構建與它的表示分離，使得同樣的構建過程可以建立不同的表示。

Chain of Responsibility 職責鏈：為解除請求的傳送者和接收者之間耦合，而使多個物件都有機會處理這個請求。將這些物件連成一條鏈，並沿著這條鏈傳遞該請求，直到有一個物件處理它。

Command（命令模式）：將一個請求封裝為一個物件，從而使你可用不同的請求對客戶進行引數化；對請求排隊或記錄請求日誌，以及支援可取消的操作。

Composite 組合模式：將物件組合成樹形結構以表示“部分-整體”的層次結構。它使得客戶對單個物件和複合物件的使用具有一致性。

Decorator 裝飾器：動態地給一個物件新增一些額外的職責。就擴充套件功能而言， 它比生成子類方式更為靈活。

Facade（外觀模式）：為子系統中的一組介面提供一個一致的介面， F a c a d e模式定義了一個高層介面，這個介面使得這一子系統更加容易使用。

Factory Method 工廠方法：定義一個用於建立物件的介面，讓子類決定將哪一個類例項化。Factory Method使一個類的例項化延遲到其子類。

Flyweight（享元模式）：運用共享技術有效地支援大量細粒度的物件。

Interpreter（Interpreter模式）：給定一個語言,定義它的文法的一種表示，並定義一個直譯器,該直譯器使用該表示來解釋語言中的句子。

Iterator 迭代器：提供一種方法順序訪問一個聚合物件中各個元素,而又不需暴露該物件的內部表示。

Mediator 中介者：用一箇中介物件來封裝一系列的物件互動。中介者使各物件不需要顯式地相互引用，從而使其耦合鬆散，而且可以獨立地改變它們之間的互動。

Memento（備忘錄模式）：在不破壞封裝性的前提下，捕獲一個物件的內部狀態，並在該物件之外儲存這個狀態。這樣以後就可將該物件恢復到儲存的狀態。

Observer（觀察者模式）：定義物件間的一種一對多的依賴關係,以便當一個物件的狀態發生改變時,所有依賴於它的物件都得到通知並自動重新整理。

Prototype（原型模式）：用原型例項指定建立物件的種類，並且通過拷貝這個原型來建立新的物件。

Proxy（代理模式）：為其他物件提供一個代理以控制對這個物件的訪問。

Singleton（單例模式）：保證一個類僅有一個例項，並提供一個訪問它的全域性訪問點。

State（狀態）：允許一個物件在其內部狀態改變時改變它的行為。物件看起來似乎修改了它所屬的類。

Strategy（策略模式）：定義一系列的演算法,把它們一個個封裝起來,並且使它們可相互替換。本模式使得演算法的變化可獨立於使用它的客戶。

Template Method 模板方法：定義一個操作中的演算法的骨架，而將一些步驟延遲到子類中。Template Method使得子類可以不改變一個演算法的結構即可重定義該演算法的某些特定步驟。

Visitor（訪問者模式）：表示一個作用於某物件結構中的各元素的操作。它使你可以在不改變各元素的類的前提下定義作用於這些元素的新操作。

5. 設計模式六大原則

1）設計模式的核心原則是:"開-閉"原則( Open - ClosedPrinciple 縮寫:OCP )：對擴充套件開放，對修改關閉

意思是,在一個系統中,對於擴充套件是開放的,對於修改是關閉的,一個好的系統是在不修改原始碼的情況下,可以擴充套件你的功能..而實現開閉原則的關鍵就是抽象化.

通過擴充套件已有軟體系統，可以提供新的行為，以滿足對軟體的新的需求，使變化中的軟體有一定的適應性和靈活性。已有軟體模組，特別是最重要的抽象層模組不能再修改，這使變化中的軟體系統有一定的穩定性和延續性。
在"開-閉"原則中,不允許修改的是抽象的類或者介面,允許擴充套件的是具體的實現類,抽象類和介面在"開-閉"原則中扮演著極其重要的角色..即要預知可能變化的需求.又預見所有可能已知的擴充套件..所以在這裡"抽象化"是關鍵!!!

可變性的封閉原則:找到系統的可變因素,將它封裝起來..這是對"開-閉"原則最好的實現..不要把你的可變因素放在多個類中,或者散落在程式的各個角落..你應該將可變的因素,封套起來..並且切忌不要把所用的可變因素封套在一起..最好的解決辦法是,分塊封套你的可變因素!!避免超大類,超長類,超長方法的出現!!給你的程式增加藝術氣息,將程式藝術化是我們的目標!!

2） 里氏代換原則:任何基類可以出現的地方,子類也可以出現

Liskov Substitution Principle（里氏代換原則）：子類能夠必須能夠替換基類能夠從出現的地方。子類也能在基類 的基礎上新增行為。這yi講的是基類和子類的關係，只有這種關係存在時，里氏代換原則才存在。正方形是長方形是理解里氏代換原則的經典例子。

3） 依賴倒轉原則:：要依賴抽象,而不要依賴具體的實現.

依賴倒置（Dependence Inversion Principle）原則講的是：要依賴於抽象，不要依賴於具體。簡單的說，依賴倒置原則要求客戶端依賴於抽象耦合。原則表述：

（1）抽象不應當依賴於細節；細節應當依賴於抽象；
（2）要針對介面程式設計，不針對實現程式設計。

如果說開閉原則是目標,依賴倒轉原則是到達"開閉"原則的手段..如果要達到最好的"開閉"原則,就要儘量的遵守依賴倒轉原則..可以說依賴倒轉原則是對"抽象化"的最好規範!!我個人感覺,依賴倒轉原則也是里氏代換原則的補充..你理解了里氏代換原則,再來理解依賴倒轉原則應該是很容易的..

4）合成/聚合複用原則（CARP）:要儘量使用合成/聚合原則,而不是繼承關係達到軟體複用的目的

合成/聚合複用原則（Composite/Aggregate ReusePrinciple或CARP）經常又叫做合成複用原則（Composite ReusePrinciple或CRP），就是在一個新的物件裡面使用一些已有的物件，使之成為新物件的一部分；新物件通過向這些物件的委派達到複用已有功能的目的。簡而言之，要儘量使用合成/聚合，儘量不要使用繼承。

要儘量使用合成/聚合原則,而不是繼承關係達到軟體複用的目的。此原則和里氏代換原則氏相輔相成的,兩者都是具體實現"開-閉"原則的規範..違反這一原則:就無法實現"開-閉"原則..先來看看什麼是合成,什麼是聚合.

什麼是合成?
合成:是指一個整體對依託他而存在的關係,例如:一個人對他的房子和傢俱,其中他的房子和傢俱是不能被共享的,因為那些東西都是他自己的..並且人沒了,這個也關係就沒了..這個例子就好像,烏雞百鳳丸這個產品,它是有烏雞和上等藥材合成而來的一樣..也比如網路遊戲中的武器裝備合成一樣,多種東西合併為一種超強的東西一樣..

什麼是聚合?
聚合:聚合是比合成關係的一種更強的依賴關係,聚合是一個整體對個體的部分,例如,一個賓士S360汽車,對賓士S360引擎,賓士S360輪胎的關係..這些關係就是帶有聚合性質的..因為賓士S360引擎和賓士S360輪胎他們只能被賓士S360汽車所用,離開了賓士S360汽車,它們就失去了存在的意義..在我們的設計中,這樣的關係不應該頻繁出現..這樣會增大設計的耦合度..
明白了合成和聚合關係,再來理解合成/聚合原則應該就清楚了..要避免在系統設計中出現,一個類的繼承層次超過3次..如果這樣的話,可以考慮重構你的程式碼,或者重新設計結構..當然最好的辦法就是考慮使用合成/聚合原則...

5）迪米特法則:系統中的類,儘量不要與其他類互相作用,減少類之間的耦合度

迪米特法則（Law of Demeter或簡寫LoD）又叫最少知識原則（Least Knowledge Principle或簡寫為LKP），也就是說，一個物件應當對其它物件有儘可能少的瞭解。

其它表述：只與你直接的朋友們通訊，不要跟"陌生人"說話。一個類應該對自己需要耦合或呼叫的類知道得最少，你（被耦合或呼叫的類）的內部是如何複雜都和我沒關係，那是你的事情，我就知道你提供的public方法，我就呼叫這麼多，其他的一概不關心。

迪米特法則與設計模式Facade模式、Mediator模式使民無知

系統中的類,減少類之間的耦合度,因為在你的系統中,擴充套件的時候,你可能需要修改這些類,而類與類之間的關係,決定了修改的複雜度,相互作用越多,則修改難度就越大,反之,如果相互作用的越小,則修改起來的難度就越小..例如A類依賴B類,則B類依賴C類,當你在修改A類的時候,你要考慮B類是否會受到影響,而B類的影響是否又會影響到C類..如果此時C類再依賴D類的話,呵呵,我想這樣的修改有的受了..

6）介面隔離法則:這個法則與迪米特法則是相通的

介面隔離原則（Interface Segregation Principle）講的是：使用多個專門的介面比使用單一的總介面總要好。換而言之，從一個客戶類的角度來講：一個類對另外一個類的依賴性應當是建立在最小介面上的。

過於臃腫的介面是對介面的汙染。不應該強迫客戶依賴於它們不用的方法。

迪米特法則是目的,而介面隔離法則是對迪米特法則的規範..為了做到儘可能小的耦合性,我們需要使用介面來規範類,用介面來約束類.要達到迪米特法則的要求,最好就是實現介面隔離法則,實現介面隔離法則,你也就滿足了迪米特法則...

6. 總結

設計模式是從許多優秀的軟體系統中總結出的成功的、能夠實現可維護性複用的設計方案，使用這些方案將避免我們做一些重複性的工作，而且可以設計出高質量的軟體系統。

設計模式的主要優點如下：

1）設計模式融合了眾多專家的經驗，並以一種標準的形式供廣大開發人員所用，它提供了一套通用的設計詞彙和一種通用的語言以方便開發人員之間溝通和交流，使得設計方案更加通俗易懂。對於使用不同程式語言的開發和設計人員可以通過設計模式來交流系統設計方案，每一個模式都對應一個標準的解決方案，設計模式可以降低開發人員理解系統的複雜度。

2）設計模式使人們可以更加簡單方便地複用成功的設計和體系結構，將已證實的技術表述成設計模式也會使新系統開發者更加容易理解其設計思路。設計模式使得重用成功的設計更加容易，並避免那些導致不可重用的設計方案。

3）設計模式使得設計方案更加靈活，且易於修改。

4）設計模式的使用將提高軟體系統的開發效率和軟體質量，且在一定程度上節約設計成本。

5）設計模式有助於初學者更深入地理解面向物件思想，一方面可以幫助初學者更加方便地閱讀和學習現有類庫與其他系統中的原始碼，另一方面還可以提高軟體的設計水平和程式碼質量。

設計模式不是學出來的，是用出來的。為了學習設計模式而學習，效果可能不是很好。一般框架都會使用設計模式。如PHP 的ZF用來很多設計模式，框架裡面的類名或者目錄名，都以某種設計模式的名稱命名，這樣大家一看到這個類名或者檔名，就知道它的程式碼組織結構了。如果精通了語言,剩下的編碼自然是很簡單,隨著編碼經驗積累,對設計模式和原則的理解也就越透徹，其過程就是山窮水復疑無路，而結果柳暗花明又一村。

另外需要注意，熟練模式後，切勿因模式二去模式。如果像著名數學家華羅庚談到讀書的三個境界所說，“讀書是由薄到厚，再由厚到薄的過程”。說明你練到家了。

優秀程式設計的18大原則

良好的程式設計原則與良好的設計工程原則密切相關。本文總結的這些設計原則，幫助開發者更有效率的編寫程式碼，並幫助成為一名優秀的程式設計師。作者Diggins是加拿大一位有25年程式設計經驗的資深技術人員，曾效力於Microsoft和Autodesk，並創辦過兩家贏利的網際網路公司。

　　1.避免重複原則(DRY - Don't repeat yourself)

　　程式設計的最基本原則是避免重複。在程式程式碼中總會有很多結構體，如迴圈、函式、類等等。一旦你重複某個語句或概念，就會很容易形成一個抽象體。

　　2.抽象原則(Abstraction Principle )

　　與DRY原則相關。要記住，程式程式碼中每一個重要的功能，只能出現在原始碼的一個位置。

　　3.簡單原則(Keep It Simple and Stupid )

　　簡單是軟體設計的目標，簡單的程式碼佔用時間少，漏洞少，並且易於修改。

　　4.避免建立你不要的程式碼 Avoid Creating a YAGNI (You aren't going to need it)

　　除非你需要它，否則別建立新功能。

　　5.儘可能做可執行的最簡單的事(Do the simplest thing that could possibly work)

　　儘可能做可執行的最簡單的事。在程式設計中，一定要保持簡單原則。作為一名程式設計師不斷的反思“如何在工作中做到簡化呢?”這將有助於在設計中保持簡單的路徑。

　　6.別讓我思考(Don't make me think )

　　這是Steve Krug一本書的標題，同時也和程式設計有關。所編寫的程式碼一定要易於讀易於理解，這樣別人才會欣賞，也能夠給你提出合理化的建議。相反，若是繁雜難解的程式，其他人總是會避而遠之的。

　　7.開閉原則(Open/Closed Principle)

　　你所編寫的軟體實體(類、模組、函式等)最好是開源的，這樣別人可以拓展開發。不過，對於你的程式碼，得限定別人不得修改。換句話說，別人可以基於你的程式碼進行拓展編寫，但卻不能修改你的程式碼。

　　8.程式碼維護(Write Code for the Maintainer)

　　一個優秀的程式碼，應當使本人或是他人在將來都能夠對它繼續編寫或維護。程式碼維護時，或許本人會比較容易，但對他人卻比較麻煩。因此你寫的程式碼要儘可能保證他人能夠容易維護。用書中原話說“如果一個維護者不再繼續維護你的程式碼，很可能他就有想殺了你的衝動。”

　　9.最小驚訝原則(Principle of least astonishment)

　　最小驚訝原則通常是在使用者介面方面引用，但同樣適用於編寫的程式碼。程式碼應該儘可能減少讓讀者驚喜。也就是說，你編寫的程式碼只需按照專案的要求來編寫。其他華麗的功能就不必了，以免弄巧成拙。

　　10.單一責任原則(Single Responsibility Principle)

　　某個程式碼的功能，應該保證只有單一的明確的執行任務。

　　11.低耦合原則(Minimize Coupling)

　　程式碼的任何一個部分應該減少對其他區域程式碼的依賴關係。儘量不要使用共享引數。低耦合往往是完美結構系統和優秀設計的標誌。

　　12.最大限度凝聚原則(Maximize Cohesion)

　　相似的功能程式碼應儘量放在一個部分。

　　13.隱藏實現細節(Hide Implementation Details)

　　隱藏實現細節原則，當其他功能部分發生變化時，能夠儘可能降低對其他元件的影響。

　　14.迪米特法則又叫作最少知識原則(Law of Demeter)

　　該程式碼只和與其有直接關係的部分連線。(比如：該部分繼承的類，包含的物件，引數傳遞的物件等)。

　　15.避免過早優化(Avoid Premature Optimization)

　　除非你的程式碼執行的比你想像中的要慢，否則別去優化。假如你真的想優化，就必須先想好如何用資料證明，它的速度變快了。

　　“過早的優化是一切罪惡的根源”——Donald Knuth

　　16.程式碼重用原則(Code Reuse is Good)

　　重用程式碼能提高程式碼的可讀性，縮短開發時間。

　　17.關注點分離(Separation of Concerns)

　　不同領域的功能，應該由不同的程式碼和最小重迭的模組組成。

　　18.擁抱改變(Embrace Change)

　　這是Kent Beck一本書的標題，同時也被認為是極限程式設計和敏捷方法的宗旨。

　　許多其他原則都是基於這個概念的，即你應該積極面對變化。事實上，一些較老的程式設計原則如最小化耦合原則都是為了使程式碼能夠容易變化。無論你是否是個極限程式設計者，基於這個原則去編寫程式碼會讓你的工作變得更有意義。

更多關於PHP相關內容感興趣的讀者可檢視本站專題：《php面向物件程式設計入門教程》、《PHP陣列(Array)操作技巧大全》、《PHP基本語法入門教程》、《PHP運算與運算子用法總結》、《php字串(string)用法總結》、《php+mysql資料庫操作入門教程》及《php常見資料庫操作技巧彙總》

希望本文所述對大家PHP程式設計有所幫助。