前言
穿衣打扮是现在的时尚潮流，我们时常刷淘宝来不断满足自己的打扮需求，买个帽子、换条裤子、整双时尚鞋。需求是没有极限的，无止境的购物，只要存在这个平台那么这些装饰性的购物是不可避免的。这在我们软件开发中可以看做是为我们实例化的对象添加一些额外的功能，要是我们对于每个都定义个子类来继承的话，那就是指数增长，根本没有头。那么我们但是这种无止境的职责是添加是行不通的，此时装饰模式登场。通过动态的给对象添加另一个职责来解决。
装饰模式Decorator：动态的给一个对象添加一些额外的职责，就增加功能来说，装饰模式比生成子类更为灵活。
理解：设计书上的例子将人和服饰分离，就跟分层似的。把服饰做一个接口让人这个类来调用，这样就很好的分离开了，人使用接口，扩展时实现接口，体现了依赖于抽象的原则。
Component(被装饰对象超类):定义对象的接口,可以给这些对象动态地添加职责.
ConcreteComponent(具体被装饰对象):定义具体的对象,Decortor可以给它增加额外的职责.
Decorator(装饰者抽象类):维护一个指向Component实例的引用,并定义了与 Component一致的接口
ConcreDecorator(具体装饰者):给内部具体被装饰对象增加具体的职责.
装饰模式结构图
总结：
看着书上面的总结很好，我们在这里就用用吧。我觉得装饰模式，是为已有功能动态的添加更多功能的一种方法。但是到底什么时候用它呢？
在本文的最初设计中，当系统需要添加新功能的时候，是向旧的类中添加新的代码，这些新增的代码通常装饰了原有类的核心职能或主要行为。这种设计方式问题在于，他们在主类中增加了新的字段、新的方法、新的逻辑，从而增加了主类的负责度，就行起初的那个人类，而这些新加入的东西仅仅是为了满足一些在某种特定情况下才会执行的特殊行为的需求。
但是装饰模式提供了一个非常好的解决方案，它把每个要装饰的功能放在单独的类中，并让这个类包含它所要装饰的对象，因此，当执行特殊行为时，在viewController里就可以根据需求有选择、按顺序的使用装饰功能包装对象了。
通过这样的解决方案，我们可以把自己捂得很严实，也可以清凉的省布料。
装饰模式的优点：
1.把类中的装饰功能从类中搬移出去，这样可以简化原有的类。
2.当有效的把类中的核心功能和装饰功能区分开了，可以去除相关类中重复的装饰逻辑。
