PHP設(shè)計(jì)模式概論【概念、分類、原則等】

本文實(shí)例講述了PHP設(shè)計(jì)模式。分享給大家供大家參考，具體如下：

1. 設(shè)計(jì)模式

設(shè)計(jì)模式（Design pattern）是一套被反復(fù)使用、多數(shù)人知曉的、經(jīng)過分類編目的、代碼設(shè)計(jì)經(jīng)驗(yàn)的總結(jié)。使用設(shè)計(jì)模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性。 毫無疑問，設(shè)計(jì)模式于己于他人于系統(tǒng)都是多贏的，設(shè)計(jì)模式使代碼編制真正工程化，設(shè)計(jì)模式是軟件工程的基石，如同大廈的一塊塊磚石一樣。
模式的經(jīng)典定義：每個(gè)模式都描述了一個(gè)在我們的環(huán)境中不斷出現(xiàn)的問題，然后描述了該問題的解決方案的核心，通過這種方式，我們可以無數(shù)次地重用那些已有的解決方案，無需再重復(fù)相同的工作。即模式是在特定環(huán)境中解決問題的一種方案

2. 設(shè)計(jì)模式 目的

其目的就是一方面教你如何利用真實(shí)可靠的設(shè)計(jì)來組織代碼的模板。 簡單地說，就是從前輩們在程序設(shè)計(jì)過程中總結(jié)、抽象出來的通用優(yōu)秀經(jīng)驗(yàn)。主要目的一方面是為了增加程序的靈活性、可重用性。 另一方面也有助于程序設(shè)計(jì)的標(biāo)準(zhǔn)化和提高系統(tǒng)開發(fā)進(jìn)度。

也有人忠告：不要過于注重程序的“設(shè)計(jì)模式”。 有時(shí)候，寫一個(gè)簡單的算法，要比引入某種模式更容易。在多數(shù)情況下，程序代碼應(yīng)是簡單易懂，甚至清潔工也能看懂。不過呢在大項(xiàng)目或者框架中，沒有設(shè)計(jì)模式來組織代碼，別人是不易理解的。

一個(gè)軟件設(shè)計(jì)模型也僅僅只是一個(gè)引導(dǎo)。它必須根據(jù)程序設(shè)計(jì)語言和你的應(yīng)用程序的特點(diǎn)和要求而特別的設(shè)計(jì)。

3. 設(shè)計(jì)模式歷史

設(shè)計(jì)模式”這個(gè)術(shù)語最初被設(shè)計(jì)用于建筑學(xué)領(lǐng)域。Christopher Alexander 在他1977的著作“A Pattern Language :Towns/Building/Construction”里面描述了一些常見的建筑學(xué)設(shè)計(jì)問題，并解釋了如何用這些已有的，著名的模式集合來開始全新 的有效的設(shè)計(jì)。Alexander的觀點(diǎn)被很好的轉(zhuǎn)化到軟件開發(fā)上來，并且長期的合意的用原有的組件來構(gòu)造新的解決方案。

4. 設(shè)計(jì)模式的四個(gè)基本要素

設(shè)計(jì)模式使人們可以更加簡單方便地復(fù)用成功的設(shè)計(jì)和體系結(jié)構(gòu)。將已證實(shí)的技術(shù)表述成設(shè)計(jì)模式也會(huì)使新系統(tǒng)開發(fā)者更加容易理解其設(shè)計(jì)思路。

所有的設(shè)計(jì)模式都有一些常用的特性：一個(gè)標(biāo)識(shí)（a pattern name），一個(gè)問題陳述（a problem statement）和一個(gè)解決方案(a solution)，效果(consequences)

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

一個(gè)設(shè)計(jì)模式的標(biāo)識(shí)（模式名稱）是重要的，因?yàn)樗鼤?huì)讓其他的程序員不用進(jìn)行太深入的學(xué)習(xí)就能立刻理解你的代碼的目的（至少通過這個(gè)標(biāo)識(shí)程序員會(huì)很熟悉這個(gè)模式）。沒有這個(gè)模式名，我們便無法與其他人交流設(shè)計(jì)思想及設(shè)計(jì)結(jié)果。

問題(problem) ：描述是用來說明這個(gè)模式的應(yīng)用的領(lǐng)域。

描述了應(yīng)該在何時(shí)使用模式。它解釋了設(shè)計(jì)問題和問題存在的前因后果，它可能描述了特定的設(shè)計(jì)問題，如怎樣用對(duì)象表示算法等。也可能描述了導(dǎo)致不靈活設(shè)計(jì)的類或?qū)ο蠼Y(jié)構(gòu)。有時(shí)候，問題部分會(huì)包括使用模式必須滿足的一系列先決條件。

解決方案(solution) ： 描述了這個(gè)模型的執(zhí)行。
描述了設(shè)計(jì)的組成成分，它們之間的相互關(guān)系及各自的職責(zé)和協(xié)作方式。因?yàn)槟Ｊ骄拖褚粋€(gè)模板，可應(yīng)用于多種不同場合，所以解決方案并不描述一個(gè)特定而具體的設(shè)計(jì)或?qū)崿F(xiàn)，而是提供設(shè)計(jì)問題的抽象描述和怎樣用一個(gè)具有一般意義的元素組合（類或?qū)ο蠼M合）來解決這個(gè)問題。

效果(consequences)

描述了模式應(yīng)用的效果及使用模式應(yīng)權(quán)衡的問題。盡管我們描述設(shè)計(jì)決策時(shí)，并不總提到模式效果，但它們對(duì)于評(píng)價(jià)設(shè)計(jì)選擇和理解使用模式的代價(jià)及好處具有重要意義。軟件效果大多關(guān)注對(duì)時(shí)間和空間的衡量，它們也表述了語言和實(shí)現(xiàn)問題。因?yàn)閺?fù)用是面向?qū)ο笤O(shè)計(jì)的要素之一，所以模式效果包括它對(duì)系統(tǒng)的靈活性、擴(kuò)充性或可移植性的影響，顯式地列出這些效果對(duì)理解和評(píng)價(jià)這些模式很有幫助。一個(gè)好的設(shè)計(jì)模式的論述應(yīng)該覆蓋使用這個(gè)模型的優(yōu)點(diǎn)和缺點(diǎn)。

一個(gè)模式是解決特定問題的有效方法。一個(gè)設(shè)計(jì)模式不是一個(gè)庫（能在你的項(xiàng)目中直接包含和使用的代碼庫）而是一個(gè)用來組織你的代碼的模板（Java bean）。事實(shí)上，一個(gè)代碼庫和一個(gè)設(shè)計(jì)模式在應(yīng)用上是有很多不同的。

比如，你從店鋪里面買的一件襯衫是一個(gè)代碼庫，它的顏色，樣式和大小都由設(shè)計(jì)師和廠商決定，但它滿足了你的需求。 然而，如果店里面沒有什么衣服適合你，那你就能自己創(chuàng)建自己的襯衫（設(shè)計(jì)它的形狀，選擇布料，然后裁縫在一起）。但是如果你不是一個(gè)裁縫，你可能會(huì)發(fā)現(xiàn)自 己很容易的去找一個(gè)合適的模式然后按著這個(gè)模式去設(shè)計(jì)自己的襯衫。使用一個(gè)模型，你可以在更少的時(shí)間內(nèi)得到一個(gè)熟練設(shè)計(jì)的襯衫。

回到討論軟件上來，一個(gè)數(shù)據(jù)提取層或者一個(gè)CMS（content management system）就是一個(gè)庫——它是先前設(shè)計(jì)好而且已經(jīng)編碼好了的，如果它能準(zhǔn)確的滿足你的需要那它就是一個(gè)好的選擇。但如果你正在讀這本書《設(shè)計(jì)模式》，可能你會(huì)發(fā)現(xiàn) 庫存的（原有的）解決方案并不是總是對(duì)你有效。至今你知道什么是你所要的，而且你能夠?qū)崿F(xiàn)它，你僅僅需要一個(gè)模型來引導(dǎo)你。

最后一個(gè)想法：就象一個(gè)裁縫模型，一個(gè)設(shè)計(jì)本身而言是沒有什么用處的。畢竟，你不可能穿一個(gè)服裝模型——它僅僅是由很薄的紙拼湊起來的。類似的，一個(gè)軟件設(shè)計(jì)模型也僅僅只是一個(gè)引導(dǎo)。它必須根據(jù)程序設(shè)計(jì)語言和你的應(yīng)用程序的特點(diǎn)和要求而特別的設(shè)計(jì)。

3. 設(shè)計(jì)模式分類

1）根據(jù)其目的（模式是用來做什么的）可分為創(chuàng)建型(Creational)，結(jié)構(gòu)型(Structural)和行為型(Behavioral)三種：
• 創(chuàng)建型模式主要用于創(chuàng)建對(duì)象。
• 結(jié)構(gòu)型模式主要用于處理類或?qū)ο蟮慕M合。
• 行為型模式主要用于描述對(duì)類或?qū)ο笤鯓咏换ズ驮鯓臃峙渎氊?zé)。

2）根據(jù)范圍，即模式主要是用于處理類之間關(guān)系還是處理對(duì)象之間的關(guān)系，可分為類模式和對(duì)象模式兩種：

• 類模式： 處理類和子類之間的關(guān)系，這些關(guān)系通過繼承建立，在編譯時(shí)刻就被確定下來，是屬于靜態(tài)的。
• 對(duì)象模式：處理對(duì)象間的關(guān)系，這些關(guān)系在運(yùn)行時(shí)刻變化，更具動(dòng)態(tài)性。

4. 一些基本的設(shè)計(jì)模式 （百度百科）

Abstract Factory（抽象工廠模式）：提供一個(gè)創(chuàng)建一系列相關(guān)或相互依賴對(duì)象的接口，而無需指定它們具體的類。 　　

Adapter（適配器模式）：將一個(gè)類的接口轉(zhuǎn)換成客戶希望的另外一個(gè)接口。A d a p t e r模式使得原本由于接口不兼容而不能一起工作的那些類可以一起工作。

Bridge（橋接模式）：將抽象部分與它的實(shí)現(xiàn)部分分離，使它們都可以獨(dú)立地變化。

Builder（建造者模式）：將一個(gè)復(fù)雜對(duì)象的構(gòu)建與它的表示分離，使得同樣的構(gòu)建過程可以創(chuàng)建不同的表示。

Chain of Responsibility 職責(zé)鏈：為解除請求的發(fā)送者和接收者之間耦合，而使多個(gè)對(duì)象都有機(jī)會(huì)處理這個(gè)請求。將這些對(duì)象連成一條鏈，并沿著這條鏈傳遞該請求，直到有一個(gè)對(duì)象處理它。

Command（命令模式）：將一個(gè)請求封裝為一個(gè)對(duì)象，從而使你可用不同的請求對(duì)客戶進(jìn)行參數(shù)化；對(duì)請求排隊(duì)或記錄請求日志，以及支持可取消的操作。

Composite 組合模式：將對(duì)象組合成樹形結(jié)構(gòu)以表示“部分-整體”的層次結(jié)構(gòu)。它使得客戶對(duì)單個(gè)對(duì)象和復(fù)合對(duì)象的使用具有一致性。

Decorator 裝飾器：動(dòng)態(tài)地給一個(gè)對(duì)象添加一些額外的職責(zé)。就擴(kuò)展功能而言， 它比生成子類方式更為靈活。

Facade（外觀模式）：為子系統(tǒng)中的一組接口提供一個(gè)一致的界面， F a c a d e模式定義了一個(gè)高層接口，這個(gè)接口使得這一子系統(tǒng)更加容易使用。

Factory Method 工廠方法：定義一個(gè)用于創(chuàng)建對(duì)象的接口，讓子類決定將哪一個(gè)類實(shí)例化。Factory Method使一個(gè)類的實(shí)例化延遲到其子類。

Flyweight（享元模式）：運(yùn)用共享技術(shù)有效地支持大量細(xì)粒度的對(duì)象。

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

Iterator 迭代器：提供一種方法順序訪問一個(gè)聚合對(duì)象中各個(gè)元素, 而又不需暴露該對(duì)象的內(nèi)部表示。

Mediator 中介者：用一個(gè)中介對(duì)象來封裝一系列的對(duì)象交互。中介者使各對(duì)象不需要顯式地相互引用，從而使其耦合松散，而且可以獨(dú)立地改變它們之間的交互。

Memento（備忘錄模式）：在不破壞封裝性的前提下，捕獲一個(gè)對(duì)象的內(nèi)部狀態(tài)，并在該對(duì)象之外保存這個(gè)狀態(tài)。這樣以后就可將該對(duì)象恢復(fù)到保存的狀態(tài)。

Observer（觀察者模式）：定義對(duì)象間的一種一對(duì)多的依賴關(guān)系,以便當(dāng)一個(gè)對(duì)象的狀態(tài)發(fā)生改變時(shí),所有依賴于它的對(duì)象都得到通知并自動(dòng)刷新。

Prototype（原型模式）：用原型實(shí)例指定創(chuàng)建對(duì)象的種類，并且通過拷貝這個(gè)原型來創(chuàng)建新的對(duì)象。

Proxy（代理模式）：為其他對(duì)象提供一個(gè)代理以控制對(duì)這個(gè)對(duì)象的訪問。

Singleton（單例模式）：保證一個(gè)類僅有一個(gè)實(shí)例，并提供一個(gè)訪問它的全局訪問點(diǎn)。

State（狀態(tài)）：允許一個(gè)對(duì)象在其內(nèi)部狀態(tài)改變時(shí)改變它的行為。對(duì)象看起來似乎修改了它所屬的類。

Strategy（策略模式）：定義一系列的算法,把它們一個(gè)個(gè)封裝起來, 并且使它們可相互替換。本模式使得算法的變化可獨(dú)立于使用它的客戶。

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

Visitor（訪問者模式）：表示一個(gè)作用于某對(duì)象結(jié)構(gòu)中的各元素的操作。它使你可以在不改變各元素的類的前提下定義作用于這些元素的新操作。

5. 設(shè)計(jì)模式六大原則

1）設(shè)計(jì)模式的核心原則是:"開-閉"原則( Open - ClosedPrinciple 縮寫:OCP )：對(duì)擴(kuò)展開放，對(duì)修改關(guān)閉

意思是,在一個(gè)系統(tǒng)中,對(duì)于擴(kuò)展是開放的,對(duì)于修改是關(guān)閉的,一個(gè)好的系統(tǒng)是在不修改源代碼的情況下,可以擴(kuò)展你的功能..而實(shí)現(xiàn)開閉原則的關(guān)鍵就是抽象化.

通過擴(kuò)展已有軟件系統(tǒng)，可以提供新的行為，以滿足對(duì)軟件的新的需求，使變化中的軟件有一定的適應(yīng)性和靈活性。已有軟件模塊，特別是最重要的抽象層模塊不能再修改，這使變化中的軟件系統(tǒng)有一定的穩(wěn)定性和延續(xù)性。
在"開-閉"原則中,不允許修改的是抽象的類或者接口,允許擴(kuò)展的是具體的實(shí)現(xiàn)類,抽象類和接口在"開-閉"原則中扮演著極其重要的角色..即要預(yù)知可能變化的需求.又預(yù)見所有可能已知的擴(kuò)展..所以在這里"抽象化"是關(guān)鍵!!!

可變性的封閉原則:找到系統(tǒng)的可變因素,將它封裝起來..這是對(duì)"開-閉"原則最好的實(shí)現(xiàn)..不要把你的可變因素放在多個(gè)類中,或者散落在程序的各個(gè)角落..你應(yīng)該將可變的因素,封套起來..并且切忌不要把所用的可變因素封套在一起..最好的解決辦法是,分塊封套你的可變因素!!避免超大類,超長類,超長方法的出現(xiàn)!!給你的程序增加藝術(shù)氣息,將程序藝術(shù)化是我們的目標(biāo)!!

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

Liskov Substitution Principle（里氏代換原則）：子類能夠必須能夠替換基類能夠從出現(xiàn)的地方。子類也能在基類 的基礎(chǔ)上新增行為。這yi講的是基類和子類的關(guān)系，只有這種關(guān)系存在時(shí)，里氏代換原則才存在。正方形是長方形是理解里氏代換原則的經(jīng)典例子。

3） 依賴倒轉(zhuǎn)原則:：要依賴抽象,而不要依賴具體的實(shí)現(xiàn).

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

（1）抽象不應(yīng)當(dāng)依賴于細(xì)節(jié)；細(xì)節(jié)應(yīng)當(dāng)依賴于抽象；
（2）要針對(duì)接口編程，不針對(duì)實(shí)現(xiàn)編程。

如果說開閉原則是目標(biāo),依賴倒轉(zhuǎn)原則是到達(dá)"開閉"原則的手段..如果要達(dá)到最好的"開閉"原則,就要盡量的遵守依賴倒轉(zhuǎn)原則..可以說依賴倒轉(zhuǎn)原則是對(duì)"抽象化"的最好規(guī)范!!我個(gè)人感覺,依賴倒轉(zhuǎn)原則也是里氏代換原則的補(bǔ)充..你理解了里氏代換原則,再來理解依賴倒轉(zhuǎn)原則應(yīng)該是很容易的..

4）合成/聚合復(fù)用原則（CARP）:要盡量使用合成/聚合原則,而不是繼承關(guān)系達(dá)到軟件復(fù)用的目的

合成/聚合復(fù)用原則（Composite/Aggregate ReusePrinciple或CARP）經(jīng)常又叫做合成復(fù)用原則（Composite ReusePrinciple或CRP），就是在一個(gè)新的對(duì)象里面使用一些已有的對(duì)象，使之成為新對(duì)象的一部分；新對(duì)象通過向這些對(duì)象的委派達(dá)到復(fù)用已有功能的目的。簡而言之，要盡量使用合成/聚合，盡量不要使用繼承。

要盡量使用合成/聚合原則,而不是繼承關(guān)系達(dá)到軟件復(fù)用的目的。此原則和里氏代換原則氏相輔相成的,兩者都是具體實(shí)現(xiàn)"開-閉"原則的規(guī)范..違反這一原則:就無法實(shí)現(xiàn)"開-閉"原則..先來看看什么是合成,什么是聚合.

什么是合成?
合成:是指一個(gè)整體對(duì)依托他而存在的關(guān)系,例如:一個(gè)人對(duì)他的房子和家具,其中他的房子和家具是不能被共享的,因?yàn)槟切〇|西都是他自己的..并且人沒了,這個(gè)也關(guān)系就沒了..這個(gè)例子就好像,烏雞百鳳丸這個(gè)產(chǎn)品,它是有烏雞和上等藥材合成而來的一樣..也比如網(wǎng)絡(luò)游戲中的武器裝備合成一樣,多種東西合并為一種超強(qiáng)的東西一樣..

什么是聚合?
聚合:聚合是比合成關(guān)系的一種更強(qiáng)的依賴關(guān)系,聚合是一個(gè)整體對(duì)個(gè)體的部分,例如,一個(gè)奔馳S360汽車,對(duì)奔馳S360引擎,奔馳S360輪胎的關(guān)系..這些關(guān)系就是帶有聚合性質(zhì)的..因?yàn)楸捡YS360引擎和奔馳S360輪胎他們只能被奔馳S360汽車所用,離開了奔馳S360汽車,它們就失去了存在的意義..在我們的設(shè)計(jì)中,這樣的關(guān)系不應(yīng)該頻繁出現(xiàn)..這樣會(huì)增大設(shè)計(jì)的耦合度..
明白了合成和聚合關(guān)系,再來理解合成/聚合原則應(yīng)該就清楚了..要避免在系統(tǒng)設(shè)計(jì)中出現(xiàn),一個(gè)類的繼承層次超過3次..如果這樣的話,可以考慮重構(gòu)你的代碼,或者重新設(shè)計(jì)結(jié)構(gòu)..當(dāng)然最好的辦法就是考慮使用合成/聚合原則...

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

迪米特法則（Law of Demeter或簡寫LoD）又叫最少知識(shí)原則（Least Knowledge Principle或簡寫為LKP），也就是說，一個(gè)對(duì)象應(yīng)當(dāng)對(duì)其它對(duì)象有盡可能少的了解。

其它表述：只與你直接的朋友們通信，不要跟"陌生人"說話。一個(gè)類應(yīng)該對(duì)自己需要耦合或調(diào)用的類知道得最少，你（被耦合或調(diào)用的類）的內(nèi)部是如何復(fù)雜都和我沒關(guān)系，那是你的事情，我就知道你提供的public方法，我就調(diào)用這么多，其他的一概不關(guān)心。

迪米特法則與設(shè)計(jì)模式Facade模式、Mediator模式使民無知

系統(tǒng)中的類,盡量不要與其他類互相作用,減少類之間的耦合度,因?yàn)樵谀愕南到y(tǒng)中,擴(kuò)展的時(shí)候,你可能需要修改這些類,而類與類之間的關(guān)系,決定了修改的復(fù)雜度,相互作用越多,則修改難度就越大,反之,如果相互作用的越小,則修改起來的難度就越小..例如A類依賴B類,則B類依賴C類,當(dāng)你在修改A類的時(shí)候,你要考慮B類是否會(huì)受到影響,而B類的影響是否又會(huì)影響到C類..如果此時(shí)C類再依賴D類的話,呵呵,我想這樣的修改有的受了..

6）接口隔離法則:這個(gè)法則與迪米特法則是相通的

接口隔離原則（Interface Segregation Principle）講的是：使用多個(gè)專門的接口比使用單一的總接口總要好。換而言之，從一個(gè)客戶類的角度來講：一個(gè)類對(duì)另外一個(gè)類的依賴性應(yīng)當(dāng)是建立在最小接口上的。

過于臃腫的接口是對(duì)接口的污染。不應(yīng)該強(qiáng)迫客戶依賴于它們不用的方法。

迪米特法則是目的,而接口隔離法則是對(duì)迪米特法則的規(guī)范..為了做到盡可能小的耦合性,我們需要使用接口來規(guī)范類,用接口來約束類.要達(dá)到迪米特法則的要求,最好就是實(shí)現(xiàn)接口隔離法則,實(shí)現(xiàn)接口隔離法則,你也就滿足了迪米特法則...

6. 總結(jié)

設(shè)計(jì)模式是從許多優(yōu)秀的軟件系統(tǒng)中總結(jié)出的成功的、能夠?qū)崿F(xiàn)可維護(hù)性復(fù)用的設(shè)計(jì)方案，使用這些方案將避免我們做一些重復(fù)性的工作，而且可以設(shè)計(jì)出高質(zhì)量的軟件系統(tǒng)。

設(shè)計(jì)模式的主要優(yōu)點(diǎn)如下：

1）設(shè)計(jì)模式融合了眾多專家的經(jīng)驗(yàn)，并以一種標(biāo)準(zhǔn)的形式供廣大開發(fā)人員所用，它提供了一套通用的設(shè)計(jì)詞匯和一種通用的語言以方便開發(fā)人員之間溝通和交流，使得設(shè)計(jì)方案更加通俗易懂。對(duì)于使用不同編程語言的開發(fā)和設(shè)計(jì)人員可以通過設(shè)計(jì)模式來交流系統(tǒng)設(shè)計(jì)方案，每一個(gè)模式都對(duì)應(yīng)一個(gè)標(biāo)準(zhǔn)的解決方案，設(shè)計(jì)模式可以降低開發(fā)人員理解系統(tǒng)的復(fù)雜度。

2）設(shè)計(jì)模式使人們可以更加簡單方便地復(fù)用成功的設(shè)計(jì)和體系結(jié)構(gòu)，將已證實(shí)的技術(shù)表述成設(shè)計(jì)模式也會(huì)使新系統(tǒng)開發(fā)者更加容易理解其設(shè)計(jì)思路。設(shè)計(jì)模式使得重用成功的設(shè)計(jì)更加容易，并避免那些導(dǎo)致不可重用的設(shè)計(jì)方案。

3）設(shè)計(jì)模式使得設(shè)計(jì)方案更加靈活，且易于修改。

4）設(shè)計(jì)模式的使用將提高軟件系統(tǒng)的開發(fā)效率和軟件質(zhì)量，且在一定程度上節(jié)約設(shè)計(jì)成本。

5）設(shè)計(jì)模式有助于初學(xué)者更深入地理解面向?qū)ο笏枷?，一方面可以幫助初學(xué)者更加方便地閱讀和學(xué)習(xí)現(xiàn)有類庫與其他系統(tǒng)中的源代碼，另一方面還可以提高軟件的設(shè)計(jì)水平和代碼質(zhì)量。

設(shè)計(jì)模式不是學(xué)出來的，是用出來的。為了學(xué)習(xí)設(shè)計(jì)模式而學(xué)習(xí)，效果可能不是很好。一般框架都會(huì)使用設(shè)計(jì)模式。如PHP 的ZF用來很多設(shè)計(jì)模式，框架里面的類名或者目錄名，都以某種設(shè)計(jì)模式的名稱命名，這樣大家一看到這個(gè)類名或者文件名，就知道它的代碼組織結(jié)構(gòu)了。如果精通了語言,剩下的編碼自然是很簡單,隨著編碼經(jīng)驗(yàn)積累,對(duì)設(shè)計(jì)模式和原則的理解也就越透徹，其過程就是山窮水復(fù)疑無路，而結(jié)果柳暗花明又一村。

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

優(yōu)秀程序設(shè)計(jì)的18大原則

良好的編程原則與良好的設(shè)計(jì)工程原則密切相關(guān)。本文總結(jié)的這些設(shè)計(jì)原則，幫助開發(fā)者更有效率的編寫代碼，并幫助成為一名優(yōu)秀的程序員。作者Diggins是加拿大一位有25年編程經(jīng)驗(yàn)的資深技術(shù)人員，曾效力于Microsoft和Autodesk，并創(chuàng)辦過兩家贏利的互聯(lián)網(wǎng)公司。

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

　　編程的最基本原則是避免重復(fù)。在程序代碼中總會(huì)有很多結(jié)構(gòu)體，如循環(huán)、函數(shù)、類等等。一旦你重復(fù)某個(gè)語句或概念，就會(huì)很容易形成一個(gè)抽象體。

　　2.抽象原則(Abstraction Principle )

　　與DRY原則相關(guān)。要記住，程序代碼中每一個(gè)重要的功能，只能出現(xiàn)在源代碼的一個(gè)位置。

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

　　簡單是軟件設(shè)計(jì)的目標(biāo)，簡單的代碼占用時(shí)間少，漏洞少，并且易于修改。

　　4.避免創(chuàng)建你不要的代碼 Avoid Creating a YAGNI (You aren't going to need it)

　　除非你需要它，否則別創(chuàng)建新功能。

　　5.盡可能做可運(yùn)行的最簡單的事(Do the simplest thing that could possibly work)

　　盡可能做可運(yùn)行的最簡單的事。在編程中，一定要保持簡單原則。作為一名程序員不斷的反思“如何在工作中做到簡化呢?”這將有助于在設(shè)計(jì)中保持簡單的路徑。

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

　　這是Steve Krug一本書的標(biāo)題，同時(shí)也和編程有關(guān)。所編寫的代碼一定要易于讀易于理解，這樣別人才會(huì)欣賞，也能夠給你提出合理化的建議。相反，若是繁雜難解的程序，其他人總是會(huì)避而遠(yuǎn)之的。

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

　　你所編寫的軟件實(shí)體(類、模塊、函數(shù)等)最好是開源的，這樣別人可以拓展開發(fā)。不過，對(duì)于你的代碼，得限定別人不得修改。換句話說，別人可以基于你的代碼進(jìn)行拓展編寫，但卻不能修改你的代碼。

　　8.代碼維護(hù)(Write Code for the Maintainer)

　　一個(gè)優(yōu)秀的代碼，應(yīng)當(dāng)使本人或是他人在將來都能夠?qū)λ^續(xù)編寫或維護(hù)。代碼維護(hù)時(shí)，或許本人會(huì)比較容易，但對(duì)他人卻比較麻煩。因此你寫的代碼要盡可能保證他人能夠容易維護(hù)。用書中原話說“如果一個(gè)維護(hù)者不再繼續(xù)維護(hù)你的代碼，很可能他就有想殺了你的沖動(dòng)。”

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

　　最小驚訝原則通常是在用戶界面方面引用，但同樣適用于編寫的代碼。代碼應(yīng)該盡可能減少讓讀者驚喜。也就是說，你編寫的代碼只需按照項(xiàng)目的要求來編寫。其他華麗的功能就不必了，以免弄巧成拙。

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

　　某個(gè)代碼的功能，應(yīng)該保證只有單一的明確的執(zhí)行任務(wù)。

　　11.低耦合原則(Minimize Coupling)

　　代碼的任何一個(gè)部分應(yīng)該減少對(duì)其他區(qū)域代碼的依賴關(guān)系。盡量不要使用共享參數(shù)。低耦合往往是完美結(jié)構(gòu)系統(tǒng)和優(yōu)秀設(shè)計(jì)的標(biāo)志。

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

　　相似的功能代碼應(yīng)盡量放在一個(gè)部分。

　　13.隱藏實(shí)現(xiàn)細(xì)節(jié)(Hide Implementation Details)

　　隱藏實(shí)現(xiàn)細(xì)節(jié)原則，當(dāng)其他功能部分發(fā)生變化時(shí)，能夠盡可能降低對(duì)其他組件的影響。

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

　　該代碼只和與其有直接關(guān)系的部分連接。(比如：該部分繼承的類，包含的對(duì)象，參數(shù)傳遞的對(duì)象等)。

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

　　除非你的代碼運(yùn)行的比你想像中的要慢，否則別去優(yōu)化。假如你真的想優(yōu)化，就必須先想好如何用數(shù)據(jù)證明，它的速度變快了。

　　“過早的優(yōu)化是一切罪惡的根源”——Donald Knuth

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

　　重用代碼能提高代碼的可讀性，縮短開發(fā)時(shí)間。

　　17.關(guān)注點(diǎn)分離(Separation of Concerns)

　　不同領(lǐng)域的功能，應(yīng)該由不同的代碼和最小重迭的模塊組成。

　　18.擁抱改變(Embrace Change)

　　這是Kent Beck一本書的標(biāo)題，同時(shí)也被認(rèn)為是極限編程和敏捷方法的宗旨。

　　許多其他原則都是基于這個(gè)概念的，即你應(yīng)該積極面對(duì)變化。事實(shí)上，一些較老的編程原則如最小化耦合原則都是為了使代碼能夠容易變化。無論你是否是個(gè)極限編程者，基于這個(gè)原則去編寫代碼會(huì)讓你的工作變得更有意義。

更多關(guān)于PHP相關(guān)內(nèi)容感興趣的讀者可查看本站專題：《php面向?qū)ο蟪绦蛟O(shè)計(jì)入門教程》、《PHP數(shù)組(Array)操作技巧大全》、《PHP基本語法入門教程》、《PHP運(yùn)算與運(yùn)算符用法總結(jié)》、《php字符串(string)用法總結(jié)》、《php+mysql數(shù)據(jù)庫操作入門教程》及《php常見數(shù)據(jù)庫操作技巧匯總》

希望本文所述對(duì)大家PHP程序設(shè)計(jì)有所幫助。