推薦：《PHP設(shè)計模式介紹》第十一章 代理模式
因為某個對象消耗太多資源,而且你的代碼并不是每個邏輯路徑都需要此對象, 你曾有過延遲創(chuàng)建對象的想法嗎 ( if和else就是不同的兩條邏輯路徑) ? 你有想過限制訪問某個對象,也就是說,提供一組方法

若你從事過面向?qū)ο蟮膒hp開發(fā)，即使很短的時間或者僅僅通過本書了解了一些，你會知道，你可以 通過繼承改變或者增加一個類的功能，這是所有面向?qū)ο笳Z言的一個基本特性。如果已經(jīng)存在的一個php類缺少某些方法，或者須要給方法添加更多的功能（魅力），你也許會僅僅繼承這個類來產(chǎn)生一個新類—這建立在額外的代碼上。

但是產(chǎn)生子類并不總是可能或是合適的。如果 你希望改變一個已經(jīng)初始化的對象的行為，你怎么辦？或者，你希望繼承許多類的行為，改怎么辦?前一個，只能在于運行時完成，后者顯然時可能的，但是可能會導(dǎo)致產(chǎn)生大量的不同的類—可怕的事情。

問題

你如何組織你的代碼使其可以容易的添加基本的或者一些很少用到的 特性，而不是直接不額外的代碼寫在你的類的內(nèi)部？

解決方案

裝飾器模式提供了改變子類的靈活方案。裝飾器模式允許你在不引起子類數(shù)量爆炸的情況下動態(tài)的修飾對象，添加特性。

當(dāng)用于一組子類時，裝飾器模式更加有用。如果你擁有一族子類（從一個父類派生而來），你需要在與子類獨立使用情況下添加額外的特性，你可以使用裝飾器模式，以避免代碼重復(fù)和具體子類數(shù)量的增加。看看以下例子，你可以更好的理解這種觀點�？紤]一個建立在組件概念上的“form”表單庫，在那里你需要為每一個你想要表現(xiàn)的表單控制類型建立一個類。這種類圖可以如下所示：

Select and TextInput類是組件類的子類。假如你想要增加一個“labeled”帶標(biāo)簽的組件—一個輸入表單告訴你要輸入的內(nèi)容。因為任何一個表單都可能需要被標(biāo)記，你可能會象這樣繼承每一個具體的組件：

上面的類圖看起來并不怎么壞，下面讓我們再增加一些特性。表單驗證階段，你希望能夠指出一個表單控制是否合法。你為非法控制使用的代碼又一次繼承其它組件，因此又需要產(chǎn)生大量的子類：

這個類看起來并不是太壞，所以讓我們增加一些新的功能。在結(jié)構(gòu)有效性確認(rèn)中你需要指出結(jié)構(gòu)是否是有效的。你需要讓你檢驗有效性的代碼也可以應(yīng)用到其它部件，這樣不用再更多的子類上進(jìn)行有效性驗證。

這里子類溢出并不是唯一的問題。想一想那些重復(fù)的代碼，你需要重新設(shè)計你的整個類層次。有沒有更好的方法！確實，裝飾器模式是避免這種情況的好方法。

裝飾器模式結(jié)構(gòu)上類似與代理模式（參見第2章）。一個裝飾器對象保留有對對象的引用，而且忠實的重新建立被裝飾對象的公共接口。裝飾器也可以增加方法，擴展被裝飾對象的接口，任意重載方法，甚至可以在腳本執(zhí)行期間有條件的重載方法。

為了探究裝飾器模式，讓我們以前面討論過的表單組件庫為例，并且用裝飾器模式而不是繼承，實現(xiàn)“lable”和“invalidation”兩個特性。

分享：《PHP設(shè)計模式介紹》第十章 規(guī)范模式
在一個應(yīng)用軟件的成型過程中，一些意想不到的商業(yè)邏輯到處出現(xiàn)。比如，基于價格的考慮，這個任務(wù)必須減少項目；而那個任務(wù)也因為銷售稅而必須選擇合適的比率；而其它的任務(wù)也必須因為其他的特別