谈一下对装饰者模式的理解

仅属个人理解，如果有误，欢迎各位指正^_

若您熟悉echarts，又苦于不知如何写后台接口，或者您对这块很感兴趣，那么就得劳烦您跳转echarts后台接口编写思路及装饰者模式的应用;

定义

装饰模式，动态地给一个对象添加一些额外的职责，就增加功能来说，装饰模式比生成子类更为灵活。

其实白话一点讲：在不影响底层类已有功能（核心职责）的前提下（开放——封闭原则），就是拓展类的功能，拓展，拓展，一直拓展，让类具有更多的灵活性。

或许还理解不了的话，我举个例子把：

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

提前帮你捋一下，底层类是碗+面（因为这些是必需品，没有不行），其他像香菜，葱跟蒜(非必需品)这些是分人群的，不同人需求不同（类似拓展功能），有的人只要香菜，有的人全要…按照我这个思路往下走。

小A来吃饭，点了一份碗+面，不爱吃香菜，葱跟蒜——>碗+面；

小B来吃饭，点了一份碗+面，但小B特别喜欢吃香菜，就让服务员加了香菜——>碗+面+葱；

小C来吃饭，点了一份碗+面，但葱对小C情有独钟，非让小C吃，迫不得已——>碗+面+葱；

小D来吃饭，点了一份碗+面，小D也是不忌口呀，一下子配料全要——>碗+面+香菜+葱+蒜；

从以上示例中，我们可以看出，碗跟面是必须的，也就是说这两个是底层类的核心职责，其他为非必需，辅助拓展功能，总不能你让蒜也放进核心职责里面把，因为有的人吃，有的人不吃。

这些大概就是对定义的解释了…如有不当，感谢大佬指点。

设计初衷：系统需要增加新功能的时候，向旧的类添加新代码；

问题：在主类加了新字段，新的方法和逻辑，增加了主类的复杂度，但这些新加入的东西仅仅是为了满足一些只在某种特定情况下才会单独执行的特殊行为需要。

解决：装饰模式。他把每个要装饰的功能放在单独的类中，

把每个要装饰的功能放在单独的类中,并让这个类包装它所要装饰的对象,因此,当需要执行特殊行为时,客户代码就可以在运行时根据需要有选择地、按顺序地使用装饰功能包装对象。

还是白话点讲吧：

需要扩展一个类的功能，或给一个类增加附加责任。

需要动态的给一个对象增加功能，这些功能可以再动态地撤销。

谈一下对装饰者模式的理解

component：我个人理解为是一个对象接口，里面还有实现的方法（可有可无）；
Decorator：装饰抽象类,继承了 Component,从外类来扩展 Component类的功能,但对于Component来说,是无需知道 Decorator的存在的。
Concrete Decorator：就是具体的装饰对象,起到给 Component添加职责的功能。

至于代码示例，我想这些大佬们写的应该会很清楚了，我写的可能会不太好：

那我直接给大家来一个装饰者模式的实际应用吧，若您熟悉echarts，又苦于不知如何写后台接口，或者您对这块很感兴趣，那么就得劳烦您跳转echarts后台接口编写思路及装饰者模式的应用;