阅读前的知识储备
请确保在阅读本文时，曾经不止一次亲自动手敲过有关代理模式的代码。如果没有，请在积累一定的经验后阅读，相信会更有收获。也希望大神不吝指教。
什么时候要用协议和代理？
下面举一个例子，谈谈个人对代理、协议的理解，希望能够起到抛砖引玉的效果。
假设现在有这么一个任务需求：页面A需要跳转到页面B（有可能会传入一些参数），页面B填写或者处理一些信息在跳转回页面A的同时还需要把数据返回A。
不要为了用代理模式而用代理模式
代理模式只是一种设计模式，它的价值在于通过一个统一的模式，解决一个原本并不方便、甚至是几乎不可能解决的问题。也就是说当原来的、简单的编程方式无法处理一个问题的时候，才会想到运用一些设计模式（比如本文所谈的代理模式）。
举个例子，如果说页面A跳转到页面B需要传递参数。显然代理模式是可以用来传参的。但是这时候有没有必要使用代理模式呢？我的回答是——“Never”。由于是从页面A跳转到页面B，那么代码应该如下所示：
//AViewController.m
@property (strong, nonatomic) BViewController *BVC;
— （void)buttonDidClicked:(id)sender{
self.BVC = [[BViewController alloc]init];
[self.navigationController pushViewController:self.BVC animated:YES];
}显然B的viewController是作为A的viewController的一个属性的。既然A有一个指向B的指针，那么直接通过指针去操作B即可。可以对B的属性赋值，可以调用B的方法等等。
那么什么时候需要用到代理模式呢？我的回答是：“页面B向页面A传值的时候”。答案也非常显然，在页面B中，我们甚至都不知道有页面A的存在，向页面A传值就更是无从谈起了。那么此时一个可行的方案是，在页面B中定义一个协议，声明一个代理对象。在页面A中，将自己设置为页面B的代理并且完成代理方法。
由此，不难得出一个结论：
当一个对象无法直接获取到另一个对象的指针，又希望对那个变量进行一些操作时，可以使用代理模式。
代理模式到底做了什么？
我眼中的代理模式只有两个关注点：协议和代理者
协议定义了一组方法，由某一个类负责实现。
代理者作为某个类的一个属性，通常是另一个类的实例对象，可以负责完成原来这个类不方便或者无法完成的任务。
首先谈一谈代理者，在脑中重新回想一下代理模式的实现过程。在页面B中定义一个代理对象的时候，好像和定义一个普通的property非常类似（除了 weak和id《delegate》>）。这也正是我对代理的概括：代理本来就是一个属性而已，并没有非常神秘。
当然，代理者并不只是一个类普通的属性，否则我只需要重写一下B的初始化方法即可达到同样的效果：
self.BVC = [[BViewController alloc]initWithDelegate:self];然后在BViewController.m中定义一个AViewController *AVC并在初始化方法中赋值即可。
注意到代理者在定义的时候，格式往往是这样的：
id <SomeDelegate> delegate;所以我对代理的优势的理解是：
代理的核心优势在于解耦
与直接声明一个属于某个固定的类的代理者相比，声明为id的代理者具备两个明星的优势。
- 允许多个不同的类成为本类的代理。试想一下在本文例子中，如果页面B可以跳转回N个页面，如果还是通过声明一个普通对象的方式，那怎么办？
- 允许代理者的类还不固定。试想一下，UITableView也有delegate，它根本不知道那个类会成为它的代理者。
再看一看协议。协议更加简单了。协议只是定义了一组方法。在代理模式中，完全可以不用在页面B中定义一个协议，然后A再去遵循这个协议。直接调用A的方法即可。
个人认为协议的优点在于以下几点：
- 可以利用Xcode的检查机制。对于定义为@required的方法，如果实现了协议而没有实现这个方法，编译器将会有警告。这样可以防止因为疏忽，忘记实现某个代码的情况，而由于OC的运行时特性，这样的错误往往在运行阶段才会导致程序崩溃。
- 有利于代码的封装。如果一个类，实现了某个协议，那么这个协议中的方法不必在.h中被声明，就可以被定义协议的类调用。这样可以减少一个类暴露给外部的方法。
- 有利于程序的结构化与层次化。一个协议往往是解决问题的某个方法，对于一个其他的不过却类似的问题，我们只用再次实现协议即可，避免了自己再次构思一组方法。协议的继承机制使得这一有点更加强大。
说了怎么多，总结起来只有一句：代理模式并不神秘，只是一个经过了优化的小技巧（让某个类持有另一个类的指针）。代理和协议也只是让程序耦合度更低，结构感更强而已。