设计模式（二）：代理模式（委托模式）

代理模式

组成：
抽象角色：通过接口或者抽象类声明真实角色实现的业务方法
代理角色：实现抽象角色，是真实角色的代理，通过真实角色的业务逻辑方法来实现抽象方法，并可以附加自己的操作。
真实角色：实现抽象角色，定义真实角色所需要实现的业务逻辑，供代理角色调用

代理的基本作用

代理是一种通用的设计模式，在iOS中对代理设计模式支持的很好，有特定的语法来实现代理模式，OC语言可以通过@protocol实现协议。
代理主要由三部分组成：
<1>.协议：用来指定代理双方可以做什么，必须做什么。
<2>.代理：根据指定的协议，完成委托方要实现的功能。
<3>委托：根据指定的协议，指定代理去完成什么功能。

这里用一张图来阐述一下三方之间的关系

Protocol - 协议的概念

从上图中我们可以看到三方之间的关系，在实际应用中通过协议来规定代理双方的行为，协议中的内容一般都是方法列表，当然也可以定义属性，我会在后续文章中顺带讲一下协议中定义属性。

协议是公共的定义，如果只是某个类使用，我们常做的就是写在某个类中。如果是多个类使用同一个协议，建议创建一个Protocol文件，在这个文件中定义协议。遵循的协议可以被继承，例如我们常用的UITableView,由于继承自UIScrollView,所以也将UIScrollViewDelegate 继承了过来，我们可以通过代理方法获取UITableView偏移量等状态参数。

// 当前协议
@protocol LoginProtocol
-(void)userLoginWithUserName:(NSString *)username password:(NSString *)password;
@end

协议有两个修饰符@optional 和 @required, 创建一个协议如果没有声明，默认是@required 状态的。这两个修饰符只是约定代理是否强制需要遵守协议，如果@require状态的方法代理没有遵守，会报错一个黄色警告，只是起一个约束的作用，没有其他功能。

无论是@optional 还是 @required，在委托方调用代理方法时都需要在一个判断，判断代理是否实现当前方法，否则会导致崩溃

// 判断代理对象是否实现这个方法，没有实现会导致崩溃
if ([self.delegate respondsToSelector:@selector(userLoginWithUsername:password:)]){
    [self.delegate useerLoginWithUsername:self.username.text password:self.password.text];
}

下面我们将用一个小例子来讲解一下这个问题：
示例：假设我在公司正在敲代码，敲的正开心呢，突然口渴了，想喝一瓶红茶。这时我就可以拿起手机去外卖app上定一个红茶，然后外卖app就会下单给店铺并让店铺给我送过来。

这个过程中，外卖app就是我的代理，我就是委托方，我买了一瓶红茶并付给外卖app钱，这就是购买协议。我只需要从外卖app上购买就可以，具体的操作都由外卖app去处理，我只需要最后接收这瓶红茶就可以。我付的钱就是参数，最后送过来的红茶就是处理结果。

但是我买红茶的同时，我还想吃一份必胜客披萨，我需要另外向必胜客app去订餐，上面的外卖app并没有这个功能。我又向必胜客购买了一份披萨，必胜客当做我的代理去为我做这份披萨，并最后送到我手里。这就是多个代理对象，我就是委托方。

在iOS中一个代理可以有多个委托方，而一个委托方也可以有多个代理。我置顶了外卖app和必胜客两个代理，也可以再指定麦当劳等多个代理，委托方也可以为多个代理服务。

代理对象在很多情况下其实是可以复用的，可以创建多个代理对象为委托方服务，在下面将会通过一个小例子解饿少一下控制器代理的复用。

下面是一个简单的代理：

首先定义一个协议类，制定公共协议

#import
@protocol LoginProtocol
@optional
-(void)userLoginWithUsername:(NSString *)username password:(NSString *)password;
@end

定义委托类，这里简单实现了一个用户登录功能，将用户登录后的账号密码传递出去，有代理来处理具体登录细节
 

#import "LoginProtocol.h"
// 当前类是委托类。用户登录后，让代理对象去实现登录细节，委托类不需要知道具体细节。
@interface LoginViewController :UIViewController
// 通过属性设置代理对象
@property (nonatomic, weak) id delegate;
@end

实现部分：

@implemeentation LoginViewController
-(void)loginButtonClick:(UIButton *)button
{
    // 判断代理对象是否实现这个方法，没有实现会导致崩溃
    if ([self.delegate respondsToSelector:@selector(userLoginWithUsername:password:)]){
        // 调用代理对象的登录方法，代理对象去实现登录方法
        [self.delegate userLoginWithUsername:self.username.text password:self.password.text];
    }
}

代理方，实现具体的登录流程，委托方不需要知道实现细节。

// 遵守登录协议
@interface ViewController

@end

@implementation ViewController

-(void)viewDidLoad{
    [super viewDidLoad];
    LoginViewController *loginVC = [[LoginViewContrller alloc] init];
    loginVC.delegate = self;
    [self.navigationController pushViewController:loginVC animated:YES];
}

// 代理方实现具体登录协议
- (void)userLoginWithUsername:(NSString *)username password:(NSString *)password
{
    NSLog(@"username:%@,password:%@",username,password);
}

@end

代理使用原理

代理实现流程

在iOS中代理的本质就是代理对象内存的传递和操作，我们在委托类设置代理对象后，实际上只是用一个id类型的指针，将代理对象进行了一个弱饮用。委托方让代理方之行操作，实际上是委托类中向这个id类型指针指向的对象发送消息，而这个id类型指针指向的对象，就是代理对象。

通过上面这张图我们发现，其实委托方的代理属性本质上就是代理对象自身，设置委托代理属性指针指向代理对象，相当于代理对象只是在委托方中调用自己的方法，如果方法没有实现就会崩溃。从崩溃的信息上来看，就可以看出是代理方没有实现协议中的方法导致的崩溃。
而协议只是一种语法，是声明委托方中的代理属性可以调用协议中声明的方法，而协议中方法的实现还是有代理完成的，而协议方和委托方都不知道这个代理方有没有完成，也不知道怎么完成。

代理内存管理

为什么我们设置代理属性都使用weak 呢？
我们定义的指针默认都是 strong 类型，而属性的本质上也是一个成员变量和set、get方法构成的，strong 类型的指针会造成强引用，必定会影响一个对象的生命周期，这也就造成了循环引用。

上图中，由于代理对象使用强引用指针，引用创建的委托方LoginVC对象，并且成为LoginVC的代理。这就回导致LoginVC的delegate属性强引用代理对象，导致循环引用的问题，最终两个对象都无法正常释放。

我们将LoginVC对象的delegate 属性，设置为弱引用属性。这样在代理对象生命周期存在时，可以正常为我们工作，如果代理对象被释放，委托方和代理对象都不会因为内存释放导致crash。

但是这样还是存在问题。

下面两种方式都是弱引用代理对象，但是第一种在代理对象被释放后你不会导致crash，而第二种会导致崩溃。

@property (nonatomic, weak)id delegate;
@property (nonatomic, assign)id delegate;

weak 和assign 是一种“非拥有关系”的指针，通过这两种修饰符修饰的指针变量，都不会改变被引用对象的引用计数。但是在一个对象被释放后，weak会自动将指针指向nil，而assign不会。在iOS中，向nil 发送消息时不会导致崩溃的，所以assign 就会导致也指针的错误 unrecongnized selector sent to instance.
所以我们如果修饰代理属性，还是用weak修饰吧，比较安全。

控制器瘦身 - 代理对象

为什么要使用代理对象？

随着项目越来越复杂，控制器也随着业务的增加而变得越来越臃肿。对于这种情况，很多人都想到了最近比较火的MVVM设计模式。但是这种模式学习曲线很大不好掌握，对于新项目来说可以使用，对于一个已经很复杂的大中型项目，就不好懂框架这层的东西了。
在项目中用到比较多的控件应该就有UITableView了，有的页面往往UITableView的处理逻辑很多，这就是导致控制器臃肿的一个很大的原因。对于这种问题，我们可以考虑给控制器瘦身，通过代理对象的方式给控制器瘦身。

什么是代理对象

这是平常控制器使用UITableView(图画的难看，主要是意思理解就行)

 

这是我们优化之后的控制器构成

 

从上面两张图可以看出，我们将UITableView的delegate和DataSource单独拿出来，由一个代理对象类进行控制，只将必须控制器处理的逻辑传递给控制器处理。

UITableView 的数据处理、展示逻辑和简单的逻辑交互都由代理对象去处理，和控制器相关的逻辑处理传递出来，交由控制器来处理，这样控制器的工作少了很多，而且耦合度也大大降低了，这样以来，我们只需要将处理的工作交由代理对象来处理，并传入一些参数即可。

下面用一段简单的代码来实现一个简单的代理对象
 

// 代理对象.h 文件的声明
typedef void (^selectCell) (NSIndexPath *indexPath);

// 代理对象（UITableView的协议需要声明在.h文件中，不然外界再使用的时候会报警告，看起来不爽）
@interface TableViewDelegateObj :NSObject <UITableViewDelegate, UITableViewDataSource>

/** 创建代理对象实例，并将数据列表传进去
 *  代理对象将消息传递出去，是通过block的方式向外传递消息的
 *  @return 返回实例对象
 */
+ (instancetype)createTableViewDelegateWithDataList:(NSArray *)dataList selectBlock:(selectCell *)selectBlock;

@end

// 代理对象.m文件中的实现

#import "TableViewDelegateObj.h"

@interface TableViewDelegateObj ()
@property (nonatomic, strong) NSArray *dataList;
@property (nonatomic, copy) selectcell selectBlock;
@end

@implementation TableViewDelegateObj

+ (instancetype)createTableViewDelegateWithDataList:(NSArray *)dataList selectBlock:(selectCell)selectBlock{
    return [[[self class] alloc] initTableViewDelegateWithDataList:daraList selectBlock:selectBlock];
} 

- (instancetype)initTableViewDelegateWithDataList:(NSArray *)dataList selectBlock:(selectCell)selectBlock{
    if (self){
        self.dataList = dataList;
        self.selectBlock = selectBlock;
    }
    return self;
}

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {
    static NSString *identifier = @"cell";
    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:identifier];
    if (!cell) {
        cell = [[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:identifier];
    }
    cell.textLabel.text = self.dataList[indexPath.row];
    return cell;
}

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section {
    return self.dataList.count;
}

- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath {
    [tableView deselectRowAtIndexPath:indexPath animated:NO];
    // 将点击事件通过block的方式传递出去
    self.selectBlock(indexPath);
}

@end

外界控制器的调用非常简单，几行代码就搞定
 

self.tableDelegate = [TableViewDelegateObj createTableViewDelegateWithDataList:self.dataList 
                                                                   selectBlock:^(NSIndexPath *indexPath) {
    NSLog(@"点击了%ld行cell", (long)indexPath.row);
}];
self.tableView.delegate = self.tableDelegate;
self.tableView.dataSource = self.tableDelegate;

在控制器中只需要创建一个代理对象类，并将UITableView的delegate和dataSource都交给代理对象去处理，让代理对象成为UITableView的代理，解决了控制器臃肿以及和UITableView的解藕。

上面的代码只是简单的实现了点击cell的功能，如果有其他需求大多也都可以在代理对象中进行处理。使用代理对象类还有一个好处，就是如果多个UITableView逻辑一样或类似，代理对象是可以复用的。

非正式协议

简介

在iOS2.0之前还没有引入@Protocol正式协议之前，实现协议的功能主要是通过给NSObject添加Category的方式。这种通过Category的方式，相对于iOS2.0之后引入的@Protocol，就叫做非正式协议。

正如上面所说的，非正式协议一般都是以NSObject的Category的方式存在的。由于是对NSObject进行的Category，所以所有基于NSObject的子类，都接受了所定义的非正式协议。对于@Protocol来说编译器会在编译期检查语法错误，而非正式协议则不会检查是否实现。

// 由于是使用的Category，所以需要用self来判断方法是否实现
if ([self respondsToSelector:@selector(userLoginWithUsername:password:)]) {
    [self userLoginWithUsername:self.username.text password:self.password.text];
}

非正式协议中没有@Protocol的@optional和@required之分，和@Protocol一样在调用的时候，需要进行判断方法是否实现。

非正式协议示例

在iOS早期也使用了大量非正式协议，例如CALayerDelegate就是非正式协议的一种实现，非正式协议本质上就是Category。

@interface NSObject (CALayerDelegate)
- (void)displayLayer:(CALayer *)layer;
- (void)drawLayer:(CALayer *)layer inContext:(CGContextRef)ctx;
- (void)layoutSublayersOfLayer:(CALayer *)layer;
- (nullable id)actionForLayer:(CALayer *)layer forKey:(NSString *)event;
@end