(四)大话设计模式 - 装饰器模式（iOS版）

装饰器模式

装饰器模式（Decorator Pattern）允许向一个现有的对象添加新的功能，同时又不改变其结构。这种类型的设计模式属于结构型模式，它是作为现有的类的一个包装。
这种模式创建了一个装饰类，用来包装原有的类，并在保持类方法签名完整性的前提下，提供了额外的功能。
我们通过下面的实例来演示装饰器模式的用法。其中，我们将把一个形状装饰上不同的颜色，同时又不改变形状类。

换句话说
在不必改变原类文件和使用继承的情况下，动态地扩展一个对象的功能。
首先要提到的是，OC 是动态的语言，所以实现装饰器模式是很简单的。可以通过分类、扩展实现装饰器。

介绍

意图：动态地给一个对象添加一些额外的职责。就增加功能来说，装饰器模式相比生成子类更为灵活。
主要解决：一般的，我们为了扩展一个类经常使用继承方式实现，由于继承为类引入静态特征，并且随着扩展功能的增多，子类会很膨胀。
何时使用：在不想增加很多子类的情况下扩展类。
如何解决：将具体功能职责划分，同时继承装饰者模式。
**关键代码： **1、Component 类充当抽象角色，不应该具体实现。 2、修饰类引用和继承 Component 类，具体扩展类重写父类方法。

应用实例： 1、孙悟空有 72 变，当他变成"庙宇"后，他的根本还是一只猴子，但是他又有了庙宇的功能。 2、不论一幅画有没有画框都可以挂在墙上，但是通常都是有画框的，并且实际上是画框被挂在墙上。在挂在墙上之前，画可以被蒙上玻璃，装到框子里；这时画、玻璃和画框形成了一个物体。
优点：装饰类和被装饰类可以独立发展，不会相互耦合，装饰模式是继承的一个替代模式，装饰模式可以动态扩展一个实现类的功能。
缺点：多层装饰比较复杂。

使用场景： 1、扩展一个类的功能。 2、动态增加功能，动态撤销。
注意事项：可代替继承。

代码实现

我们举一个设计师帮普通人包装打扮的例子
设计师和普通人都会打扮（拥有wear行为方法） 但是设计师可以把普通人装饰的更好看

1.定义一个打扮的行为协议(接口)

#import 

NS_ASSUME_NONNULL_BEGIN

//打扮的行为接口
@protocol IDressUp 

//穿着行为
@required
-(void)wear;

@end

NS_ASSUME_NONNULL_END

2.定义一个普通人(ta具有打扮的能力)

#import 
#import "IDressUp.h"
NS_ASSUME_NONNULL_BEGIN

//人类拥有打扮的行为
@interface Human : NSObject

//穿着动作
-(void)wear;

@end

NS_ASSUME_NONNULL_END

#import "Human.h"

@implementation Human

-(void)wear {
    NSLog(@"普通人在打扮：衣服");
}

@end

3.定义一个设计师<装饰器>(ta也具有打扮的能力，但是ta可以在不影响普通人打扮的基础下额外做一些美化(扩展))

#import 
#import "IDressUp.h"
NS_ASSUME_NONNULL_BEGIN

//装饰类 (装饰human)
@interface HumanDecorator : NSObject

-(instancetype)initWithBeDecorator:(id)beDecorator;

//装饰行为
-(void)wear;

@end

NS_ASSUME_NONNULL_END

#import "HumanDecorator.h"

@interface HumanDecorator ()

@property (nonatomic,weak)idbeDecorator;

@end

@implementation HumanDecorator

-(instancetype)initWithBeDecorator:(id)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 human = nil;//声明一个人类（具有打扮行为的人）
    human = [[Human alloc] init];//创建一个具体的人类对象（多态）
    id 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 类不依赖它显示的数据。