談一下對裝飾者模式的理解

僅屬個人理解，如果有誤，歡迎各位指正^_

若您熟悉echarts，又苦於不知如何寫後臺接口，或者您對這塊很感興趣，那麼就得勞煩您跳轉echarts後臺接口編寫思路及裝飾者模式的應用;

定義

裝飾模式，動態地給一個對象添加一些額外的職責，就增加功能來說，裝飾模式比生成子類更爲靈活。

其實白話一點講：在不影響底層類已有功能（核心職責）的前提下（開放——封閉原則），就是拓展類的功能，拓展，拓展，一直拓展，讓類具有更多的靈活性。

或許還理解不了的話，我舉個例子把：

原料：碗，面，香菜，蔥，蒜。

提前幫你捋一下，底層類是碗+面（因爲這些是必需品，沒有不行），其他像香菜，蔥跟蒜(非必需品)這些是分人羣的，不同人需求不同（類似拓展功能），有的人只要香菜，有的人全要…按照我這個思路往下走。

小A來喫飯，點了一份碗+面，不愛喫香菜，蔥跟蒜——>碗+面；

小B來喫飯，點了一份碗+面，但小B特別喜歡喫香菜，就讓服務員加了香菜——>碗+面+蔥；

小C來喫飯，點了一份碗+面，但蔥對小C情有獨鍾，非讓小C喫，迫不得已——>碗+面+蔥；

小D來喫飯，點了一份碗+面，小D也是不忌口呀，一下子配料全要——>碗+面+香菜+蔥+蒜；

從以上示例中，我們可以看出，碗跟面是必須的，也就是說這兩個是底層類的核心職責，其他爲非必需，輔助拓展功能，總不能你讓蒜也放進核心職責裏面把，因爲有的人喫，有的人不喫。

這些大概就是對定義的解釋了…如有不當，感謝大佬指點。

設計初衷：系統需要增加新功能的時候，向舊的類添加新代碼；

問題：在主類加了新字段，新的方法和邏輯，增加了主類的複雜度，但這些新加入的東西僅僅是爲了滿足一些只在某種特定情況下才會單獨執行的特殊行爲需要。

解決：裝飾模式。他把每個要裝飾的功能放在單獨的類中，

把每個要裝飾的功能放在單獨的類中,並讓這個類包裝它所要裝飾的對象,因此,當需要執行特殊行爲時,客戶代碼就可以在運行時根據需要有選擇地、按順序地使用裝飾功能包裝對象。

還是白話點講吧：

需要擴展一個類的功能，或給一個類增加附加責任。

需要動態的給一個對象增加功能，這些功能可以再動態地撤銷。

component：我個人理解爲是一個對象接口，裏面還有實現的方法（可有可無）；
Decorator：裝飾抽象類,繼承了 Component,從外類來擴展 Component類的功能,但對於Component來說,是無需知道 Decorator的存在的。
Concrete Decorator：就是具體的裝飾對象,起到給 Component添加職責的功能。

至於代碼示例，我想這些大佬們寫的應該會很清楚了，我寫的可能會不太好：

那我直接給大家來一個裝飾者模式的實際應用吧，若您熟悉echarts，又苦於不知如何寫後臺接口，或者您對這塊很感興趣，那麼就得勞煩您跳轉echarts後臺接口編寫思路及裝飾者模式的應用;