此设计模式遵循的设计原则之一：类应该支持扩展，而拒绝修改（Open-Closed Principle）
装饰者模式简述
装饰者模式通过组合的方式扩展对象的特性，这种方式允许我们在任何时候对对象的功能进行扩展甚至是运行时扩展，而若我们用继承来完成对类的扩展则只能在编译阶段实现，所以在某些时候装饰者模式比继承（inheritance）要更加灵活。
装饰者模式具有的一些特征
1，装饰者（decorator）和被装饰（扩展）的对象有着相同的超类（supertype）。
2，我们可以用多个装饰者去装饰一个对象。
3，我们可以用装饰过的对象替换代码中的原对象，而不会出问题（因为他们有相同的超类）。
4，装饰者可以在委托（delegate，即调用被装饰的类的成员完成一些工作）被装饰者的行为完成之前或之后加上他自己的行为。
5，一个对象能在任何时候被装饰，甚至是运行时。
装饰者模式的基本结构
我们来看一张《Head first 设计模式》里的图
（图中的英文为书中对这个结构的解释与说明，下面的解释并不是对图中英文的直接翻译，而是博主自己的稍稍结合书中其他内容的总结）
Component:一般是一个抽象类（也有可能不是），是一组有着某种用途类的基类，包含着这些类最基本的特性。
ConcreteComponent：继承自Component，一般是一个有实际用途的类，这个类就是我们以后要装饰的对象。
Decorator：继承自Component，装饰者需要共同实现的接口（也可以是抽象类），用来保证装饰者和被装饰者有共同的超类，并保证每一个装饰者都有一些必须具有的性质，如每一个装饰者都有一个实例变量（instance variable）用来保存某个Component类型的类的引用。
ConcreteDecorator：继承自Decorator，用来装饰Component类型的类（不能装饰抽象类），为其添加新的特性，可以在委托被装饰者的行为完成之前或之后的任意时候。
一个简单的实例
我们用《Head First 设计模式》里举的星巴克订单的例子来说明。
星巴克提供不同种类的咖啡和咖啡的调料，星巴克需要一些类来描述他们并且能计算出任意一种咖啡和任意几种调料搭配在一起的价格，如果我们用继承为每一种搭配写一个类的话，就会变成下面这个样子。
要在工作中用这种东西，还不如让我们一起狗带_(:зゝ∠)_。。。。。
当然我们也可把调料都写在作为超类Beverage里，但是这样的话会造成数据的大量冗余，这是一个解决办法，但是还不够好。
如果套用上面所介绍的装饰者模式的结构就是下面这个样子
Beverage（饮料类）：相当与Component
HouseBlend、DarkRoast...（混合咖啡类、礁炒咖啡类...）：相当于ConcreteComponent
CondimentDecorator（调料装饰者类）：相当于Decorator
Milk、Mocha...（牛奶类、摩卡类...）：相当于ConcreteDecorator
装饰者模式的特点，一个ConcreteComponent可以被任意个ConcreteDecorator装饰。
结合实例就来解释，一种 咖啡 可以和任意种 调料 搭配。
这样我们来应对各种点单的搭配的时候只需要在一种咖啡（ConcreteComponent）加上各种（ConcreteDecorator）就可以完成了，是不是觉得特别方便。
以上转自https://www.cnblogs.com/coffeeSS/p/5405787.html
也就是说装饰者模式装饰者和被装饰者必须有相同的抽象超类，我们通过将被装饰者类的实例传入装饰者类（装饰者类里会有构造方法接受传入的被装饰者），接下来在装饰者类完成一系列的操作，最后返回这个装饰者，此时他就已经被装饰了。io包里就大量运用这一特性。
