装饰器模式
装饰器模式（Decorator Pattern）允许向一个现有的对象添加新的功能，同时又不改变其结构。这种类型的设计模式属于结构型模式，它是作为现有的类的一个包装。
这种模式创建了一个装饰类，用来包装原有的类，并在保持类方法签名完整性的前提下，提供了额外的功能。
我们通过下面的实例来演示装饰器模式的用法。其中，我们将把一个形状装饰上不同的颜色，同时又不改变形状类。
换句话说
在不必改变原类文件和使用继承的情况下，动态地扩展一个对象的功能。
首先要提到的是，OC 是动态的语言，所以实现装饰器模式是很简单的。可以通过分类、扩展实现装饰器。
介绍
意图：动态地给一个对象添加一些额外的职责。就增加功能来说，装饰器模式相比生成子类更为灵活。
主要解决：一般的，我们为了扩展一个类经常使用继承方式实现，由于继承为类引入静态特征，并且随着扩展功能的增多，子类会很膨胀。
何时使用：在不想增加很多子类的情况下扩展类。
如何解决：将具体功能职责划分，同时继承装饰者模式。
**关键代码： **1、Component 类充当抽象角色，不应该具体实现。 2、修饰类引用和继承 Component 类，具体扩展类重写父类方法。
应用实例： 1、孙悟空有 72 变，当他变成"庙宇"后，他的根本还是一只猴子，但是他又有了庙宇的功能。 2、不论一幅画有没有画框都可以挂在墙上，但是通常都是有画框的，并且实际上是画框被挂在墙上。在挂在墙上之前，画可以被蒙上玻璃，装到框子里；这时画、玻璃和画框形成了一个物体。
优点：装饰类和被装饰类可以独立发展，不会相互耦合，装饰模式是继承的一个替代模式，装饰模式可以动态扩展一个实现类的功能。
缺点：多层装饰比较复杂。
使用场景： 1、扩展一个类的功能。 2、动态增加功能，动态撤销。
注意事项：可代替继承。
代码实现
我们举一个设计师帮普通人包装打扮的例子
设计师和普通人都会打扮（拥有wear行为方法） 但是设计师可以把普通人装饰的更好看
1.定义一个打扮的行为协议(接口)
#import <Foundation/Foundation.h>
NS_ASSUME_NONNULL_BEGIN
//打扮的行为接口
@protocol IDressUp <NSObject>
//穿着行为
@required
-(void)wear;
@end
NS_ASSUME_NONNULL_END
2.定义一个普通人(ta具有打扮的能力)
#import <Foundation/Foundation.h>
#import "IDressUp.h"
NS_ASSUME_NONNULL_BEGIN
//人类拥有打扮的行为
@interface Human : NSObject<IDressUp>
//穿着动作
-(void)wear;
@end
NS_ASSUME_NONNULL_END
#import "Human.h"
@implementation Human
-(void)wear {
NSLog(@"普通人在打扮：衣服");
}
@end
3.定义一个设计师<装饰器>(ta也具有打扮的能力，但是ta可以在不影响普通人打扮的基础下额外做一些美化(扩展))
#import <Foundation/Foundation.h>
#import "IDressUp.h"
NS_ASSUME_NONNULL_BEGIN
//装饰类 (装饰human)
@interface HumanDecorator : NSObject<IDressUp>
-(instancetype)initWithBeDecorator:(id<IDressUp>)beDecorator;
//装饰行为
-(void)wear;
@end
NS_ASSUME_NONNULL_END
#import "HumanDecorator.h"
@interface HumanDecorator ()
@property (nonatomic,weak)id<IDressUp>beDecorator;
@end
@implementation HumanDecorator
-(instancetype)initWithBeDecorator:(id<IDressUp>)beDecorator {
if (self = [super init]) {
self.beDecorator = beDecorator;
}
return self;
}
//装饰行为 可以在需要修饰的对象 wear 前后新增一些动作（好比读配置等等）
-(void)wear {
[self beforeWear];
[self.beDecorator wear];
[self afterWear];
}
-(void)beforeWear {
NSLog(@"我是设计师：穿衣前,先选化个妆");
}
-(void)afterWear {
NSLog(@"我是设计师：穿衣后，再弄个发型");
}
@end
注意装饰的顺序(方法diap可以在里面灵活扩展添加的元素)
设计师帮助普通人打扮(装饰)
id<IDressUp> human = nil;//声明一个人类（具有打扮行为的人）
human = [[Human alloc] init];//创建一个具体的人类对象（多态）
id<IDressUp> humanDecorator = [[HumanDecorator alloc] initWithBeDecorator:human];//相当于创建一个设计师帮human包装一下
[humanDecorator wear];//设计师帮忙穿衣服（设计师持有human 可以帮助human wear，且可以在wear前后进行额外的修饰扩展操作）
运行结果
2019-03-18 18:57:32.839119+0800 DesignModeDemo[76023:1633341] 我是设计师：穿衣前,先选化个妆
2019-03-18 18:57:32.839217+0800 DesignModeDemo[76023:1633341] 普通人在打扮：衣服
2019-03-18 18:57:32.839304+0800 DesignModeDemo[76023:1633341] 我是设计师：穿衣后，再弄个发型
iOS用例场景
分类(Category)和委托(Delegation)
在 Object-C 里有两个种非常常见的实现模式：分类(Category)和委托(Delegation)。
1.分类 Category
分类是一种非常强大的机制，它允许你在一个已存在的类里添加新方法，而不需要去为他添加一个子类。新方法在编译的时候添加，它能像这个类的扩展方法一样正常执行。一个装饰器跟类的定义稍微有点不同的就是，因为装饰器不能被实例化，它只是一个扩展。
提示：除了你自己类的扩展，你还可在任何 Cocoa 类里的扩展添加方法。
2.委托 Delegation
另外一种装饰器的设计模式是，委托 (Delegation)，它是一种机制，一个对象代表另外一个对象或者其相互合作。例子，当你使用 UITableView 的时候，其中一个方法是你必需要执行的，tableView:numberOfRowsInSection:。
你可能并不期望 UITableView 知道每个 section 中有多少行，这是程序的特性。因此，计算每个 section 有多少行的工作就交给了 UITableView 的委托 (delegate)。它允许 UITableView 类不依赖它显示的数据。
