前期回顾
在上一篇中解决了第一篇最后遗留问题的第一个，在这篇文章中我们要解决遗留的第二个问题——如何使得调用过程是可控的，避免调用者无规则的随意调用。
即，如下调用：
tool.select(nil).from(@"table").from(@"table").select(nil);
从代码逻辑上讲，这段代码是没问题的，编译、运行都不会报错。但是从业务逻辑上讲，这明显是错误的，不符合SQL的规范。
所以需要改进的是，如何控制这个调用过程，使得在“SELECT”之后只能是“FROM”，而“FROM”之后只能是“WHERE”、“JOIN”等等。
分析
之所以调用者可以随意调用，是因为这些属性都是声明在.h文件中，都是公开的。既然是公开的，那么当然可以随意调用。所以这些属性是不能放在.h文件中的。那要是不放在.h文件中，调用者又如何去调用相应的属性呢？答案是——协议（Protocol）。
使用协议（Protocol）我们可以不去关心在调用时的对象实例是什么，只要知道它遵从了什么协议，就知道有哪些方法是可以被调用的。
估计会有人问，即便是使用了协议，将原有的属性放到协议里去，那么调用者不一样可以调用，跟不使用协议有啥区别？
确实，上面的质问是对的。某个类遵从了某个协议，从一定程度上讲就等同于这个类就有了协议中声明的方法可供外界调用。所以，用不用协议在这个场景下看似无关紧要。但是，如果反过来想呢，某个类遵从了协议就代表协议中方法可被调用，那要是没有遵从协议不就是无法调用了吗（这里的“无法调用”不是绝对的，只是从正常的编译角度上讲的，真想调用私用方法还是有办法的）。
也就是说，这里需要多个协议，每个协议下只有相应可供调用的方法。这些协议不是在.h文件中遵循，而是在.m中通过Class Extension遵循。在.h中公开遵循的话，又回到老路上。这样的话，允许调用者调用某个方法时，就返回遵循相应协议的实例；不允许调用某方法时，返回的实例就不遵循这个协议（说起来有点绕+_+，下面直接看代码吧）。这就是所谓的面向接口的编程（准确讲iOS中应该叫面向协议的编程）。
面向协议的改造
参照上面的分析，我们需要将原有属性移到对应的协议中去，然后作为属性的block，其返回值返回的是遵循了某个或多个协议的实例。
上代码：
.h文件
@class SQLTool;
@protocol ISelectable;
@protocol IFromable;
@protocol IJoinable;
@protocol IWhereable;
//GroupBy之类的这里就省略了
...
/*****************************/
//定义select的block，返回值是遵循了IFromable的实例对象
//即后续调用时只能调用IFromable协议的方法
typedef SQLTool <IFromable> *(^Select)(NSArray<NSString *> *columns);
//定义from的block
typedef SQLTool <IJoinable, IWhereable /* GroupBy之类的这里就省略了 */> *(^From)(NSString *tableName, NSString *alias);
//定义join的block
typedef SQLTool <IJoinable, IWhereable /* GroupBy之类的这里就省略了 */> *(^Join)(NSString *tableName, NSString *alias, NSString *on);
...
/*****************************/
@protocol ISelectable <NSObject>
@property (nonatomic, strong, readonly) Select select;
@end
@protocol IFromable <NSObject>
@property (nonatomic, strong, readonly) From from;
@end
@protocol IJoinable <NSObject>
@property (nonatomic, strong, readonly) Join leftJoin;
@property (nonatomic, strong, readonly) Join rightJoin;
@property (nonatomic, strong, readonly) Join innerJoin;
@end
@interface SQLTool : NSObject
//这里不需要了，放到.m中去
//@property (nonatomic, strong, readonly) NSString *sql;
//参数是一个block，传递一个遵循ISelectable的SQLTool的实例给调用者
+ (NSString *)makeSQL:(void(^)(SQLTool<ISelectable> *tool))block;
@end
.m文件：
//通过Class Extension让SQLTool遵循所有的协议
@interface SQLTool () <ISelectable, IFromable, IJoinable, IWhereable /* GroupBy之类的这里就省略了 */>
@property (nonatomic, strong) NSString *sql;
@end
@implementation SQLTool
+ (NSString *)makeSQL:(void(^)(SQLTool<ISelectable> *tool))block {
if (block) {
//创建遵循ISelectable协议的实例，通过block传递给调用者
SQLTool<ISelectable> *tool = [[SQLTool<ISelectable> alloc] init];
block(tool);
return tool.sql;
}
return nil;
}
- (Select)select {
return ^(NSArray<NSString *> *columns) {
if (columns.count > 0) {
self.sql = [NSString stringWithFormat:@"SELECT %@", [columns componentsJoinedByString:@","]];
} else {
self.sql = @"SELECT *";
}
//这里将自己返回出去
return self;
}
}
...
@end
这时候调用起来就不会出现本篇开头时提到的那种不规范的调用了（如果代码没有贴错的话）。因为每一步调用返回的都是只满足了部分协议的实例对象，这样就能保证接下来只能调用这些协议声明的方法（属性）了。
一些小结
对于面向接口（协议）的编程的应用，本篇的例子并不是最佳的应用场景。要说最经典的应用，当属delegate。通过delegate的模式，功能的提供者不需要知道当前的delegate是谁，只要知道这个delegate的实例遵从某个协议就行。这里可以理解为，<b>为不同的实例对象提供一个统一的调用入口</b>。这种方式应该算是面向接口的最典型的应用。
而本篇的例子刚好相反，调用者知道当前的实例是谁，只不过不知道当前遵循了什么协议。所以通过返回值的方式告诉调用者当前遵循的协议，以此来限制可供调用者调用的方法。这里可以理解为，<b>限制一个实例对象的调用行为</b>。
一方面是“提供”，一方面又是“限制”，看似矛盾的两种行为其实并不矛盾。好比事物都有两面性，只要掌握了其本质就会发现其实两方面都对的，就看如何去运用它。
最后
本篇的例子是跟着这几篇文章一起写的，所以暂时没有所谓的完整代码。有兴趣的朋友可以自己去试着写完。当然后续有空的话，我也会补充完整并上传。欢迎点评。
谢谢阅读！
