JVM:”上次給我招的工人不錯啊！”

oo程式設計師:”………..”

JVM:”現在來我開的博物館生意越來越好了，原來”舞臺劇”的方式已經不能滿足顧客的需求了”

oo程式設計師:”………..”

JVM:”我決定要換一種運營模式，把每個演播廳都租出去，讓那些想表演節目的物件們來租演播廳和相關器械，這樣我就能坐地收錢了！”

oo程式設計師:”………..”

JVM:”合夥幹吧？怎麼樣？你三我七！”

oo程式設計師:”………..”

JVM:”四六？”

oo程式設計師:”成交！先說說需求。”

JVM:”首先有不同型別的演播廳和不同的裝飾品/器械，每種物品都要付一定的租金，你要做的就是一件事，把總租金（演播廳+飾品/器械）算出來。”

oo程式設計師:”把價格表給我！”

仔細一想也對，無論是演播廳還是裝飾品，都需要描述（description）和cost（價格），寫一個共同的父類無可厚非。

接著寫下你設計的第一個類：

第二個：

第三個：

。。。。。

沒有第三個了！這樣寫下去可是無窮無盡的！沒辦法，換個思路。

在演播廳裡，無論什麼裝飾品都有可能出現，可以把演播廳+飾品看成一個整體，通過飾品相應的has和set來控制飾品，這樣的話，設計出來的類如下：

這個看起來好多了，不用寫大爆炸數量的類，雖然類寫起來又臭（無數的has/set）又長（的確很長）。。。。。

但是有沒有更好的方案？

答案當然是有的，不過我們必須先明確一下，上述設計的缺點。

1.臭

2.長

3.當飾品的租金改變的時候，必須修改所有演播廳的程式碼（cost部分），我們當然不想這樣，我們想盡可能的少修改程式碼（鬆耦合）。

4.沒有面對超類/介面程式設計。

5.沒有將變化的部分獨立開。

6.組合可能是更好的解決方案。

下面讓我們看看。裝飾者模式是如何解決上面問題的。

裝飾者模式：動態的將責任加到物件上，若要擴充套件功能，裝飾者提供了比繼承更有彈性的替代方案。

首先，我們先將演播廳和他的裝飾者們分開，讓裝飾者繼承另一個類：

讓裝飾者子類重新實現getDescription()即可。

現在我們的思路是：用裝飾者裝飾演播廳，例如，一個帶麥克風和氣球的卡通演播廳，就先讓氣球裝飾卡通演播廳，再讓麥克風裝飾“帶氣球的卡通演播廳”

先讓我們分別實現這3個類：

卡通演播廳：

氣球：

程式碼：

結果是正確的。

這樣寫很好的解決了上面的問題。

1.運用組合進行擴充套件，使當價格改變的時候，只需要修改本身的程式碼。

2.面對超類/介面程式設計，使飾品增加種類的時候，並不需要修改被裝飾者的程式碼。

3.開放——關閉原則 ：程式碼應該對擴充套件開放，對修改關閉。

缺陷：

1.子類繁多，影響理解程式碼(java I/O就是裝飾者模式哦。。。)。

2.無法應用於需要具體類的場景。

3.更多資料免費