delegate和protocol

protocol和delegate完全不是一回事，放在一起说，只是因为我们经常在同一个头文件里看到这两个word。

协议(protocol)，就是使用了这个协议后就要按照这个协议来办事，协议要求实现的方法就一定要实现。

委托(delegate)，顾名思义就是委托别人办事，就是当 一件事情发生后，自己不处理，让别人来处理。

举个浅显的例子：

我上班的工作主要内容包括 （1）写代码（2）写文档（3）测试程序（4）接电话（5）会见客户

（1）（2）我自己全权负责，但是后面（3）（4）（5）我不想或者不方便自己做，所以我想找个助手（delegate）帮我做这些事，于是我定了一个招聘要求（Protocol），里写明我的助手需要会做（3）（4）（5）这三件事。很快，我招到一个助手。

即：我.delegate = 助手;

于是以后每当我遇到需要测试程序或者接电话的活，我就把他转交给助手（delegate）去处理，助手处理完后如果有处理结果（返回值）助手会告诉我，也许我会拿来用。如果不需要或者没有结果，我就接着做下面的事。。

protocol和java里interface的概念类似，是Objective-C语法的一部分。

定义protocol如下

C代码

1. 1. 
      
2. @protocol ClassADelegate
3. 
   
4. - (void)methodA;
5. - (void)methodB;
6. 
   
7. @end
   1. 
      

那么就是定义了一组函数，这组函数放在一起叫作一个protocol，也就是协议。

函数是需要被实现的，所以如果对于class如下

C代码

1. 1. 
      
2. @interface ClassB <ClassADelegate> {
3. }
4. @end
   1. 
      

就叫作ClassB conform to protocol ClassADelegate，也就是说ClassB实现了这个协议，

也就是实现了这一组函数。

有了上面这个头文件，我们就可以放心作调用

C代码

1. 1. 
      
2. ClassB *b = [[ClassB alloc] init];
3. [b methodA];
4. [b methodB];
   1. 
      

而不用担心出现unrecognized selector sent to instance这种错误了。

所以protocol就是一组函数定义，是从类声明中剥离出来的一组定义。

C代码

1. 1. 
      
2. id<ClassADelegate> b = ...;
3. [b methodA];
   1. 
      

这种用法也常见，b是一个id类型，它知道ClassADelegate这组函数的实现。

那么delegate是什么？其实和protocol没有关系。Delegate本身应该称为一种设计模式。

是把一个类自己需要做的一部分事情，让另一个类（也可以就是自己本身）来完成。

比如ClassC

C代码

1. 1. 
      
2. @interface ClassC {
3. id delegate;
4. }
5. @end
   1. 
      

那么ClassC的实现(.m文件)里就可以用delegate这个变量了。

当然这里完全可以用其它名字而不是delegate。

我们也可以这样写

C代码

1. 1. 
      
2. @interface ClassC {
3. ClassB *delegate;
4. }
5. @end
   1. 
      

这样我们知道了delegate是一个ClassB，它就可以提供ClassB里的方法。

可以把一部分ClassC里的工作放在ClassB里去实现。

这样的写法看起来是不是有点奇怪？或者应该写成这样？

C代码

1. 1. 
      
2. @interface ClassC {
3. ClassB *classB;
4. }
5. @end
6. …
   1. 
      

delegate没有了…

所以说其实delegate只是一种模式，大家约定俗成，当把自己内部一部分实现暴露给另外一个类去做的时候，就叫实际做事的类为delegate。

为什么会需要把内部实现提出来给另一个类做呢？

最常见的目的就是为了在隐藏实现的前提下，提供一个自定义的机会。

比如Apple提供的iOS SDK里就有众多的delegate，比如最常用的UITableView，

我们没法知道Apple怎么重用UITableViewCell，怎么处理UITableView里Cell的增加、删减，因为我们没有源码。

但是我们可以通过实现Delegate的方法来控制一个UITableView的一些行为。

UITableViewDataSource其实和delegate是一样一样的，只是由于意义不同换了个名字罢了。

protocol在此扮演了什么角色呢？

protocol是一种语法，它提供了一个很方便的、实现delegate模式的机会。

比如写UITableView的时候，Apple这么干

UITableView.m

C代码

1. 1. 
      
2. - (void)doSomething {
3. [self blahblah];
4. 
   
5. [self.delegate guruguru];
6. 
   
7. [self blahblah];
8. }
   1. 
      

delegate是我们写的类，这个类如果可以被传给UITableView做为其delegate，那唯一要求，就是它实现了

- (void)guruguru;

这个方法。

如果我们把这个方法定义在一个protocol里

C代码

1. 1. 
      
2. @protocol XXXProtocol
3. 
   
4. - (void)guruguru;
5. 
   
6. @end
   1. 
      

就说明了，UITableView需要的delegate是一个conform to XXXProtocol的类。

这就正好是

id<XXXProtocol>

表达的意思。

无论具体的类是什么，它还有其它什么方法，只要它conform to这个protocol，

就说明它可以被传给UITableView，作为它的delegate。

那么Apple为了让我们知道这个protocol是delegate需要conform的protocol，

它就把XXXProtocol改成了UITableViewDelegate

这样我们看到protocol的名字里有Delegate，就知道这个protocol里的函数是用来做自定义(Customization)的了。

​

Protocol 的其它问题

1. 使用时为什么要加上 iOS.delegate = self

物件名称.delegate = self，是在採用任何协定时 一定会看到的一行程式码，由于定义协定的类别并不需要实作协定内的方法，因为实作的部份是由採纳协定的类别来实作，但是它又必须要知道是由哪一个类别来实作，因此我们必须要把採纳协定类别的 instance 交给定义协定的类别，让它来使用。

另一方面并不是任何类别都可以将 instance 传给定义协定的类别来使用，其原因是，我们在定义此协定的类别里有宣告 delegate 变数时，有限定它必须要採纳此协定（id delegate）如果没有採用该协定就将 instance 传给定义该协定的类别，Xcode 同样会发出警告讯息。

2. 为什么协定的生效位置不能写在建构式中

协定的生效位置写在建构式中，并不会造成程式编译上的任何问题，因为这是属于逻辑上的错误，协定要正常生效它必须要知道实作它方法的类别的 instance，如果将生效的位置写在建构式中，在建立定义此协定的形态的变物件时，它的确会去触发此协定内的方法，但是由于并没有给它实作此协定方法类别的 instance，因此不会有任何效果产生，反之，如果一定要将生效的位置写在建构式中，那么在初始化时就必须要设定好 delegate 才行，也就是使用初始化的方法函式里还必须要带入一个参数物件好指定给 delegate。

3. 在定义协定时同时也可以採用其他的协定

如果在定义协定时同时又採用其他的协定，这会导致之后採纳此协定的类别，它必须同时实作出两个协定内的方法，同样地，你也可以利用此方式来扩充那些已经存在的协定。

C代码

1. 1. 
      
2. @protocol FurnaceDelegate <其它可能的协定名称>
   1. 
      

4. 使用 @optional 提供选择性的实作

@optional，如同它字面上的意义，在 @optional 之后的方法都可以是选择性的实作，在定义协定时使用此方法，可以让之后採纳此协定的类别不一定要完全实作出协定内的所有方法。

C代码

1. 1. 
      
2. @protocol FurnaceDelegate
3. - (void)whenCalledDelegeteFunction;
4. 
   
5. @optional
6. -(void)optionalDelegeteFunction;
7. 
   
8. @end
   1. 
      

​