前期回顧
在上一篇中解決了第一篇最后遺留問題的第一個，在這篇文章中我們要解決遺留的第二個問題——如何使得調(diào)用過程是可控的，避免調(diào)用者無規(guī)則的隨意調(diào)用。
即，如下調(diào)用：
tool.select(nil).from(@"table").from(@"table").select(nil);
從代碼邏輯上講，這段代碼是沒問題的，編譯、運行都不會報錯。但是從業(yè)務(wù)邏輯上講，這明顯是錯誤的，不符合SQL的規(guī)范。
所以需要改進的是，如何控制這個調(diào)用過程，使得在“SELECT”之后只能是“FROM”，而“FROM”之后只能是“WHERE”、“JOIN”等等。
分析
之所以調(diào)用者可以隨意調(diào)用，是因為這些屬性都是聲明在.h文件中，都是公開的。既然是公開的，那么當然可以隨意調(diào)用。所以這些屬性是不能放在.h文件中的。那要是不放在.h文件中，調(diào)用者又如何去調(diào)用相應(yīng)的屬性呢？答案是——協(xié)議（Protocol）。
使用協(xié)議（Protocol）我們可以不去關(guān)心在調(diào)用時的對象實例是什么，只要知道它遵從了什么協(xié)議，就知道有哪些方法是可以被調(diào)用的。
估計會有人問，即便是使用了協(xié)議，將原有的屬性放到協(xié)議里去，那么調(diào)用者不一樣可以調(diào)用，跟不使用協(xié)議有啥區(qū)別？
確實，上面的質(zhì)問是對的。某個類遵從了某個協(xié)議，從一定程度上講就等同于這個類就有了協(xié)議中聲明的方法可供外界調(diào)用。所以，用不用協(xié)議在這個場景下看似無關(guān)緊要。但是，如果反過來想呢，某個類遵從了協(xié)議就代表協(xié)議中方法可被調(diào)用，那要是沒有遵從協(xié)議不就是無法調(diào)用了嗎（這里的“無法調(diào)用”不是絕對的，只是從正常的編譯角度上講的，真想調(diào)用私用方法還是有辦法的）。
也就是說，這里需要多個協(xié)議，每個協(xié)議下只有相應(yīng)可供調(diào)用的方法。這些協(xié)議不是在.h文件中遵循，而是在.m中通過Class Extension遵循。在.h中公開遵循的話，又回到老路上。這樣的話，允許調(diào)用者調(diào)用某個方法時，就返回遵循相應(yīng)協(xié)議的實例；不允許調(diào)用某方法時，返回的實例就不遵循這個協(xié)議（說起來有點繞+_+，下面直接看代碼吧）。這就是所謂的面向接口的編程（準確講iOS中應(yīng)該叫面向協(xié)議的編程）。
面向協(xié)議的改造
參照上面的分析，我們需要將原有屬性移到對應(yīng)的協(xié)議中去，然后作為屬性的block，其返回值返回的是遵循了某個或多個協(xié)議的實例。
上代碼：
.h文件
@class SQLTool;
@protocol ISelectable;
@protocol IFromable;
@protocol IJoinable;
@protocol IWhereable;
//GroupBy之類的這里就省略了
...
/*****************************/
//定義select的block，返回值是遵循了IFromable的實例對象
//即后續(xù)調(diào)用時只能調(diào)用IFromable協(xié)議的方法
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;
//參數(shù)是一個block，傳遞一個遵循ISelectable的SQLTool的實例給調(diào)用者
+ (NSString *)makeSQL:(void(^)(SQLTool<ISelectable> *tool))block;
@end
.m文件：
//通過Class Extension讓SQLTool遵循所有的協(xié)議
@interface SQLTool () <ISelectable, IFromable, IJoinable, IWhereable /* GroupBy之類的這里就省略了 */>
@property (nonatomic, strong) NSString *sql;
@end
@implementation SQLTool
+ (NSString *)makeSQL:(void(^)(SQLTool<ISelectable> *tool))block {
if (block) {
//創(chuàng)建遵循ISelectable協(xié)議的實例，通過block傳遞給調(diào)用者
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
這時候調(diào)用起來就不會出現(xiàn)本篇開頭時提到的那種不規(guī)范的調(diào)用了（如果代碼沒有貼錯的話）。因為每一步調(diào)用返回的都是只滿足了部分協(xié)議的實例對象，這樣就能保證接下來只能調(diào)用這些協(xié)議聲明的方法（屬性）了。
一些小結(jié)
對于面向接口（協(xié)議）的編程的應(yīng)用，本篇的例子并不是最佳的應(yīng)用場景。要說最經(jīng)典的應(yīng)用，當屬delegate。通過delegate的模式，功能的提供者不需要知道當前的delegate是誰，只要知道這個delegate的實例遵從某個協(xié)議就行。這里可以理解為，<b>為不同的實例對象提供一個統(tǒng)一的調(diào)用入口</b>。這種方式應(yīng)該算是面向接口的最典型的應(yīng)用。
而本篇的例子剛好相反，調(diào)用者知道當前的實例是誰，只不過不知道當前遵循了什么協(xié)議。所以通過返回值的方式告訴調(diào)用者當前遵循的協(xié)議，以此來限制可供調(diào)用者調(diào)用的方法。這里可以理解為，<b>限制一個實例對象的調(diào)用行為</b>。
一方面是“提供”，一方面又是“限制”，看似矛盾的兩種行為其實并不矛盾。好比事物都有兩面性，只要掌握了其本質(zhì)就會發(fā)現(xiàn)其實兩方面都對的，就看如何去運用它。
最后
本篇的例子是跟著這幾篇文章一起寫的，所以暫時沒有所謂的完整代碼。有興趣的朋友可以自己去試著寫完。當然后續(xù)有空的話，我也會補充完整并上傳。歡迎點評。
謝謝閱讀！
