現在進入下一個分類。

　　類型2：結構 - 裝飾者設計模式

　　我將為您提供一個小場景，以便更好地說明為什么以及在何處使用裝飾器模式。

　　假設你擁有一家咖啡店，像任何新手一樣，你從兩種普通咖啡開始，即家庭混合咖啡和深色烘焙咖啡。在您的計費系統中，有一個用于不同咖啡混合的類，該類繼承了飲料抽象類。人們實際上開始過來喝你的美妙(盡管很苦?)咖啡。然后是咖啡新手，上帝保佑，他們想要糖或牛奶。咖啡真是太嘲諷了!!??

　　現在，您還需要將這兩個附加組件也放在菜單上，不幸的是，在計費系統上。最初，您的IT人員將為兩種咖啡制作一個子類，一種包括糖，另一種包括牛奶。然后，既然客戶總是對的，人們會說這些可怕的話：

　　“我能喝點加糖的牛奶咖啡嗎?”

　　???

　　你的計費系統再次在你的臉上笑了起來。好吧，回到繪圖板.

　　然后，IT 人員將含糖的牛奶咖啡作為另一個子類添加到每個父咖啡類中。這個月剩下的時間一帆風順，人們排隊喝咖啡，你實際上賺錢了。??

　　但是，等等，還有更多!

　　世界再次與你作對。一個競爭對手在街對面打開，不僅有4種咖啡，還有10多種附加組件!

　　你買了所有這些甚至更多，自己賣更好的咖啡，然后記住你忘了更新那個沉悶的計費系統。您很可能無法為所有附加組件的任何和所有組合制作無限數量的子類，也可以使用新的咖啡混合物。更不用說最終系統的大小了。

　　是時候實際投資適當的計費系統了。你找到新的IT人員，他們實際上知道他們在做什么，他們說，

　　“為什么，如果它使用裝飾器圖案，這將變得容易得多，也更小。

　　那到底是什么?

　　裝飾器設計模式屬于結構類別，該類別處理類的實際結構，無論是通過繼承，組合還是兩者兼而有之。此設計的目標是在運行時修改對象的功能。這是許多其他設計模式之一，它們利用抽象類和具有組合的接口來獲得所需的結果。

　　讓我們給數學一個機會(不寒而栗?)，把這一切帶入視角。

　　取 4 種混合咖啡和 10 種附加組件。如果我們堅持為一種咖啡的所有附加組件的每個不同組合生成子類。那是：

　　(10–1)² = 9² = 81 個子類

　　我們從10中減去1，因為你不能將一個附加組件與另一個相同類型的附加組件組合在一起，糖與糖聽起來很愚蠢。而這只適用于一種咖啡混合物。將81乘以4，你會得到一個驚人的324個不同的子類!談論所有這些編碼...

　　但是對于裝飾器模式，在這種情況下，它只需要16個類。想下注嗎?

　　裝飾器設計模式類圖

　　根據咖啡店場景的類圖

　　如果我們根據上面的類圖繪制我們的場景，我們將得到4個咖啡混合物的4個類，每個附加組件10個，抽象組件1個，抽象裝飾器1個。看!260 億現在交出那100美元.??(jk，但如果給予，它不會被拒絕...只是說)

　　從上面可以看出，正如具體的咖啡混合物是飲料抽象類的子類一樣，AddOn抽象類也從它繼承了它的方法。附加組件(即其子類)依次繼承任何新方法，以便在需要時向基對象添加功能。

　　讓我們開始編碼，看看這個模式在使用中。

　　首先制作抽象飲料類，所有不同的咖啡混合物將繼承自：

　　然后添加兩個具體的咖啡混合類。

　　AddOn 抽象類也繼承自飲料抽象類(下面將對此進行詳細介紹)。

　　現在是這個抽象類的具體實現：

　　如您在上面看到的，我們可以將飲料的任何子類傳遞給AddOn的任何子類，并獲得額外的成本以及更新的描述。而且，由于 AddOn 類本質上是飲料類型，我們可以將一個插件傳遞到另一個插件中。通過這種方式，我們可以將任意數量的附加組件添加到特定的咖啡混合物中。

　　現在編寫一些代碼來測試它。

　　最終結果是：

　　它的工作原理!我們能夠向咖啡混合物添加多個附加組件，并成功更新其最終成本和描述，而無需為所有咖啡混合物的每個附加組合制作無限的子類。