前言
何為協議，簡單來說在OC中我們使用關鍵字@protocol可以聲明一個協議，并在協議中添加多個屬性、方法供于遵循者實現，從某個角度上來說，這是一種不同于category機制的category。在日常開發中，協議可謂無處不在，最為核心的UITableView通過協議來獲取數據、完成事件處理等。下面就是一個最粗淺的協議
@protocol CustomProtocol
- (void)doSomething;
@end
對于協議的理解，很多的開發者依舊保留在委托-代理等于協議等認知上。然而前者依賴于后者的實現，而后者即便不通過前者也能完成抽象解耦的工作。在繼續談協議可以完成的工作之前，有必要來理解一下何為協議：
協議指定了一套行為規范，遵循協議的類必須實現對應的行為
協議應用
代理回調
開發中我們幾乎都會寫的代碼一定是UITableView系列的代理和數據源方法。毫無疑問，蘋果提供的這個視圖是如此的優雅而強大，即便在現在這個數據源方法因代碼過多被瘋狂吐槽的年代，你依然無法想到其他實現UITableView的更佳實踐，這個控件充分向我們展示了委托-代理的強大。
協議最簡單直觀的應用是
委托-代理設計模式，在封裝自定義控件的時候，我喜歡使用自定義的協議來完成用戶點擊等業務處理。個人認為，如果你想要了解代理這一模式，起碼要自定義過自己的代理協議：
@protocol SegmentControlDelegate
@optional
- (void)segmentControl: (SegmentControl *)segmentControl didSelectItemAtIndex: (NSUInteger)index;
@end
@interface SegmentControl: UIView
@property (nonatomic, weak) id<SegmentControlDelegate> delegate;
@end
@implementation SegmentControl
- (voice)clickItem: (UIButton *)item
{
if ([_delegate respondsToSelector: @selector(segmentControl:didSelectItemAtInex:)]) {
[_delegate segmentControl: self didSelectItemAtIndex: item.tag];
}
}
@end
上面是我曾經自定義過的分段控制器的代理偽實現代碼，對于項目開發而言，代理這種回調機制的好處包括不僅于接口目的性強、易于追溯調試等。
什么時候用代理
這里不免就要提到另一個跟Delegate同樣實用受歡迎的機制Block。比如常用的分享功能通常使用block進行結果回調：
typedef NS_ENUM(NSInteger, ShareResult) {
ShareResultSuccess,
ShareResultFailed,
ShareResultCancel
};
- (void)share {
[shareManager shareWithResult: ^(ShareResult result) {
switch (result) {
case ShareResultSuccess:
//....
case ShareResultFailed:
//....
case ShareResultCancel:
//....
}
}];
}
這樣的代碼看著很緊湊簡潔，如果用Delegate來完成結果回調又是另一種感覺了：
- (void)share
{
ShareManager * shareManager = [[ShareManager alloc] initWithUrl: @"http://sindrilin.com" title: @"" content: @""];
shareManager.delegate = self;
[shareManager share];
}
- (void)shareManager: (ShareManager *)shareManager didCompleteShare: (ShareResult)result
{
switch (result) {
case ShareResultSuccess:
//....
case ShareResultFailed:
//....
case ShareResultCancel:
//....
}
}
同樣的代碼在Delegate看著并不nice。這是什么原因呢？個人認為原因如下：
- 由于代理沒有
Block的捕獲上下文特性，需要傳入調用方參數。但在方法中，ShareManager并沒有任何作用 - 相較于
block，代理將分享步驟和結果處理分到兩個地方，邏輯不夠緊湊
同樣的，假如上面的分享換成網絡請求，并且要求在請求中同步下載進度，單純的使用Block可能就會變成這樣：
- (void)requestData {
[manager requestWithProgress: ^(CGFloat progress) {
NSLog(@"download progress: %g", progress);
self.progressView.progress = progress;
} complete: ^(id receiveData, NSError * error) {
if (error) {
[self showErrorWithMsg: error.description];
} else {
// handle receive data
}
}];
}
這個時候的Block就會有些雜亂，看著頭疼。通過這種對比，我們不難看出如果你需要執行某個任務，并且在任務完成的時候執行額外的操作時，Block的使用效果優于代理。而如果某個事件是存在多種狀態，在每個狀態發生或者改變時需要回調的，定義一個協議來回調是更好的選擇。
數據源
雖然蘋果將代理分為了數據源和代理兩種類型，但是本質上都歸屬于委托-代理機制。蘋果沒有介紹過兩者應當怎么劃分，單從字面上的意思來劃分這兩者大概是這樣的：
- 數據源為控件提供了數據展示的接口
- 代理為控件提供了事件響應的接口
這里要說的大概就是假如我們自定義了控件的數據源，那么應該什么時候調用數據源？按照UITableView的使用來說，當存在下面幾種情況的時候，數據源方法是不調用的：
- UITableView未添加到視圖上
- UITableView的寬高其中一個值為0
- UITableView沒設置代理
首先是前兩個問題，作為所有視圖父類的UIView中開放了一個方法didMoveToSuperview，這個方法會在當前視圖被addSubview:之后回調。因此我們需要重寫這個方法并且從數據源獲取數據：
@protocol CustomViewDataSource<NSObject>
- (CustomViewCell *)customView: (CustomView *)customView cellForRowAtIndexPath: (IndexPath *)indexPath;
@end
@interface CustomView
@property (nonatomic, weak) id<CustomViewDataSource> dataSource;
@end
@implementation CustomView
- (void)didMoveToSuperview
{
[super didMoveToSuperview];
if (!_delegate) { return; }
if ( CGRectGetWidth(self.frame) == 0 || CGRectGetHeight(self.frame) == 0 ) { return; }
for (IndexPath * index in _visableIndexPaths) {
id cell = [_dataSource customView: self cellForRowAtIndexPath: index];
// configure cell
[self addSubview: cell];
}
}
@end
與didMoveToSuperview類似的還有didMoveToWindow，這個方法會在前一個方法調用的前后分別調用一次，適當的重寫這兩個方法可以盡量讓一些數據源方法調用延后，從而減少了同一時間大量方法調用降低幀數的可能性。
同樣是委托-代理機制，數據源的使用要比單純的代理考慮的因素多了許多。因此，數據源的使用算是協議應用的進一步。
協議抽象
在這里我們要聊聊面向對象編程，幾乎有經驗的開發者都能隨口說出面向對象編程的特性：多態、抽象、封裝、這些特性大大的提高了猿們的生產力，但這種便利并不是沒有代價的，在Casa大神跳出面向思想系列就提出了繼承的缺陷。
然而，這和本文有什么關系？
在iPad開發中有一個特殊的控件UISplitViewController，它將屏幕分割成大小兩部分并同時顯示兩個控制器視圖。其中左側作為管理視圖，右側為詳細信息視圖。如果在右側詳情視圖存在多個的情況下，左側點擊發生事件時，可能需要一堆的配置創建控制器的代碼：
#import "AppDelegate.h"
#import "AddContactViewController.h"
#import "ContactDetailViewController.h"
@interface MasterViewController ()
@property (nonatomic, weak) UISplitViewController * splitViewController;
@property (nonatomic, strong) NSArray * contacts;
@end
@implementation MasterViewController
- (void)viewDidLoad
{
[super viewDidLoad];
AppDelegate * appDelegate = (AppDelegate *)[UIApplication sharedApplication].delegate;
self.splitViewController = appDelegate.splitViewController;
}
- (void)contactDetail: (NSInteger)index
{
ContactDetailViewController * contactDetailVC = [[ContactDetailViewController alloc] init];
contactDetailVC.contact = _contacts[index];
[_splitViewController showDetailViewController: contactDetailVC sender: self];
}
- (void)addContact
{
AddContactViewController * addContactVC = [[AddContactViewController alloc] initWithNibName: @"AddContactViewController" bundle: nil];
[_splitViewController showDetailViewController: addContactVC sender: self];
}
@end
實際上需求當中右側包含的界面包括何止十來個，還不包括復雜的nib控制器，這樣就導致了左側視圖MasterViewController非常的亂。一方面，雖然只是弱指針引用，但是MasterViewController依舊需要獲取所在的splitViewController。另一方面，太多的控制器創建配置代碼雷同而多余。通過使用協議讓這些壞毛病變得不那么壞。對于右側的顯示控制器，定義一個用于初始化的類構造方法，將右側控制器的創建統一化；以及一個配置數據的方法：
@protocol DetailViewControllerProtocol
+ (instancetype)detailViewController;
- (void)configurateWithData: (id)data;
@end
另一方面，為左側的控制器定義一個回調代理，傳入將要顯示的右側控制器類名以及配置數據，讓splitViewController自己來完成界面顯示：
/// MasterViewController.h
@protocol MasterViewControllerDelegate
- (void)showDetailWithClass: (Class)aClass data: (id)data;
@end
@interface MasterViewController: NSObject
@property (nonatomic, weak) id<MasterViewControllerDelegate> delegate;
@end
/// MasterViewController.m
@implementation MasterViewController- (void)contactDetail: (NSInteger)index
- (void)contactDetail: (NSInteger)index
{
[self showDetail: NSClassFromString(@"ContactDetailViewController") data: _contacts[index]];
}
- (void)addContact
{
[self showDetail: NSClassFromString(@"AddContactViewController") data: nil];
}
- (void)showDetail: (Class)aClass data: (id)data
{
if ([_delegate respondsToSelector: @selector(showDetailWithClass:data:)]) {
[_delegate showDetailWithClass: aClass data: data];
}
}
@end
改動之后MasterViewController只保留了數據以及右側控制器的名稱，其余的工作交給代理人也就是UISplitViewController來完成：
#import "MasterViewController.h"
#import "DetailViewControllerProtocol.h"
@interface SplitViewController ()<MasterViewControllerDelegate>
@end
@implementation SplitViewController
- (void)viewDidLoad
{
[super viewDidLoad];
for (UIViewController * viewController in self.viewControllers) {
if ([viewController isKindOfClass: [MasterViewController class]]) {
MasterViewController * masterVC = (MasterViewController *)viewController;
masterVC.delegate = self;
break;
}
}
}
- (void)showDetailWithClass: (Class)aClass data: (id)data
{
UIViewController<DetailViewControllerProtocol> * detailVC = [aClass detailViewController];
[detailVC configurateWithData: data];
[self showDetailViewController: detailVC sender: self];
}
@end
最后就是右側不同的控制器實現協議方法，完成控制器的創建和配置：
@implementation ContactDetailViewController
+ (instancetype)detailViewController
{
return [[[self class] alloc] init];
}
- (void)configurateWithData: (Contact *)data
{
self.phone = data.phone;
self.fullName = data.fullName;
}
@end
@implementation AddContactViewController
+ (instancetype)detailViewController
{
return [[[self class] alloc] initWithNibName: NSStringFromClass([self class) bundle: nil];
}
- (void)configurateWithData: (id)data { }
/// More. Load from storyboard etc
@end
實際上上面的例子是通過協議將不同控制器統一的行為（創建、配置）抽象成協議，從而減少了重復代碼的使用。這種抽象統一的好處在于耦合度低，任何控制器只要實現了協議就能很好的在這個splitViewController上使用展示。
結束語
曾幾何時，在懵懂中自學iOS時，總是不能理解協議的用處。甚至在接觸了Block的時候，覺得這tm的太好用了，代理有個毛卵用。然后一直濫用Block直到發現并沒有那么的神，往往還會帶來隱晦的bug，于是才重新撿起了Delegate。從那之后逐漸的開始嘗試包括通知、代理、Block多種回調方式的自定義控件，因此，本文嚴格來說算是紀錄曾經的一次成長。
轉載請注明本文作者以及地址
