來大同小異；如果妳覺得發起網絡請求並解析數據需要壹大段代碼，加上刷新和加載後簡直復雜度爆表，如果妳想知道為什麽下面的代碼可以滿足上述所有要求：
MVC
系好安全帶，上車！
在討論解耦之前，我們要弄明白 MVC 的核心：控制器（以下簡稱 C）負責模型（以下簡稱 M）和視圖（以下簡稱 V）的交互。
這裏所說的 M，通常不是壹個單獨的類，很多情況下它是由多個類構成的壹個層。最上層的通常是以Model結尾的類，它直接被 C 持有。Model類還可以持有兩個對象：
Item：它是實際存儲數據的對象。它可以理解為壹個字典，和 V 中的屬性壹壹對應
Cache：它可以緩存自己的 Item（如果有很多）
常見的誤區：
壹般情況下數據的處理會放在 M 而不是 C（C 只做不能復用的事）
解耦不只是把壹段代碼拿到外面去。而是關註是否能合並重復代碼， 並且有良好的拖展性。
原始版
在 C 中，我們創建UITableView對象，然後將它的數據源和代理設置為自己。也就是自己管理著 UI 邏輯和數據存取的邏輯。在這種架構下，主要存在這些問題：
違背 MVC 模式，現在是 V 持有 C 和 M。
C 管理了全部邏輯，耦合太嚴重。
其實絕大多數 UI 相關都是由 Cell 而不是UITableView自身完成的。
為了解決這些問題，我們首先弄明白，數據源和代理分別做了那些事。
數據源
它有兩個必須實現的代理方法：
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section;
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath;
簡單來說，只要實現了這個兩個方法，壹個簡單的 UITableView 對象就算是完成了。
除此以外，它還負責管理 section 的數量，標題，某壹個 cell 的編輯和移動等。
代理
代理主要涉及以下幾個方面的內容：
cell、headerView 等展示前、後的回調。
cell、headerView 等的高度，點擊事件。
最常用的也是兩個方法：
- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath;
- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath;
提醒：絕大多數代理方法都有壹個 indexPath 參數
優化數據源
最簡單的思路是單獨把數據源拿出來作為壹個對象。
這種寫法有壹定的解耦作用，同時可以有效減少 C 中的代碼量。然而總代碼量會上升。我們的目標是減少不必要的代碼。
比如獲取每壹個 section 的行數，它的實現邏輯總是高度類似。然而由於數據源的具體實現方式不統壹，所以每個數據源都要重新實現壹遍。
SectionObject
首先我們來思考壹個問題，數據源作為 M，它持有的 Item 長什麽樣？答案是壹個二維數組，每個元素保存了壹個 section
所需要的全部信息。因此除了有自己的數組（給cell用）外，還有 section 的標題等，我們把這樣的元素命名為 SectionObject：
@interface KtTableViewSectionObject : NSObject
@property (nonatomic, copy) NSString *headerTitle; // UITableDataSource 協議中的 titleForHeaderInSection 方法可能會用到
@property (nonatomic, copy) NSString *footerTitle; // UITableDataSource 協議中的 titleForFooterInSection 方法可能會用到
@property (nonatomic, retain) NSMutableArray *items;
- (instancetype)initWithItemArray:(NSMutableArray *)items;
@end
Item
其中的 items 數組，應該存儲了每個 cell 所需要的 Item，考慮到 Cell 的特點，基類的 BaseItem 可以設計成這樣：
@interface KtTableViewBaseItem : NSObject
@property (nonatomic, retain) NSString *itemIdentifier;
@property (nonatomic, retain) UIImage *itemImage;
@property (nonatomic, retain) NSString *itemTitle;
@property (nonatomic, retain) NSString *itemSubtitle;
@property (nonatomic, retain) UIImage *itemAccessoryImage;
- (instancetype)initWithImage:(UIImage *)image Title:(NSString *)title SubTitle:(NSString *)subTitle AccessoryImage:(UIImage *)accessoryImage;
@end
父類實現代碼
規定好了統壹的數據存儲格式以後，我們就可以考慮在基類中完成某些方法了。以 -
(NSInteger)tableView:(UITableView *)tableView
numberOfRowsInSection:(NSInteger)section 方法為例，它可以這樣實現：
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section {
if (self.sections.count > section) {
KtTableViewSectionObject *sectionObject = [self.sections objectAtIndex:section];
return sectionObject.items.count;
}
return 0;
}
比較困難的是創建 cell，因為我們不知道 cell 的類型，自然也就無法調用 alloc 方法。除此以外，cell 除了創建，還需要設置 UI，這些都是數據源不應該做的事。
這兩個問題的解決方案如下：
定義壹個協議，父類返回基類 Cell，子類視情況返回合適的類型。
為 Cell 添加壹個 setObject 方法，用於解析 Item 並更新 UI。
優勢
經過這壹番折騰，好處是相當明顯的：
子類的數據源只需要實現 cellClassForObject 方法即可。原來的數據源方法已經在父類中被統壹實現了。
每壹個 Cell 只要寫好自己的 setObject 方法，然後坐等自己被創建，被調用這個方法即可。
子類通過 objectForRowAtIndexPath 方法可以快速獲取 item，不用重寫。
對照 demo（SHA-1：6475496），感受壹下效果。
優化代理
我們以之前所說的，代理協議中常用的兩個方法為例，看看怎麽進行優化與解耦。
首先是計算高度，這個邏輯並不壹定在 C 完成，由於涉及到 UI，所以由 Cell 負責實現即可。而計算高度的依據就是 Object，所以我們給基類的 Cell 加上壹個類方法：
+ (CGFloat)tableView:(UITableView*)tableView rowHeightForObject:(KtTableViewBaseItem *)object;
另外壹類問題是以處理點擊事件為代表的代理方法， 它們的主要特點是都有 indexPath 參數用來表示位置。然而實際在處理過程中，我們並不關系位置，關心的是這個位置上的數據。
因此，我們對代理方法做壹層封裝，使得 C 調用的方法中都是帶有數據參數的。因為這個數據對象可以從數據源拿到，所以我們需要能夠在代理方法中獲取到數據源對象。
為了實現這壹點， 最好的辦法就是繼承 UITableView：
@protocol KtTableViewDelegate@optional
- (void)didSelectObject:(id)object atIndexPath:(NSIndexPath*)indexPath;
- (UIView *)headerViewForSectionObject:(KtTableViewSectionObject *)sectionObject atSection:(NSInteger)section;
// 將來可以有 cell 的編輯，交換，左滑等回調
// 這個協議繼承了UITableViewDelegate ，所以自己做壹層中轉，VC 依然需要實現某
@end
@interface KtBaseTableView : UITableView@property (nonatomic, assign) id ktDataSource;
@property (nonatomic, assign) id ktDelegate;
@end
cell 高度的實現如下，調用數據源的方法獲取到數據：
- (CGFloat)tableView:(UITableView*)tableView heightForRowAtIndexPath:(NSIndexPath*)indexPath {
id dataSource = (id)tableView.dataSource;
KtTableViewBaseItem *object = [dataSource tableView:tableView objectForRowAtIndexPath:indexPath];
Class cls = [dataSource tableView:tableView cellClassForObject:object];
return [cls tableView:tableView rowHeightForObject:object];
}
優勢
通過對 UITableViewDelegate 的封裝（其實主要是通過 UITableView 完成），我們獲得了以下特性：
C 不用關心 Cell 高度了，這個由每個 Cell 類自己負責
如果數據本身存在數據源中，那麽在代理協議中它可以被傳給 C，免去了 C 重新訪問數據源的操作。
如果數據不存在於數據源，那麽代理協議的方法會被正常轉發（因為自定義的代理協議繼承自 UITableViewDelegate）
對照 demo（SHA-1：ca9b261），感受壹下效果。
更加 MVC，更加簡潔
在上面的兩次封裝中，其實我們是把 UITableView 持有原生的代理和數據源，改成了 KtTableView 持有自定義的代理和數據源。並且默認實現了很多系統的方法。
到目前為止，看上去壹切都已經完成了，然而實際上還是存在壹些可以改進的地方：
目前仍然不是 MVC 模式！
C 的邏輯和實現依然可以進壹步簡化
基於以上考慮， 我們實現壹個 UIViewController 的子類，並且把數據源和代理封裝到 C 中。
@interface KtTableViewController : UIViewController@property (nonatomic, strong) KtBaseTableView *tableView;
@property (nonatomic, strong) KtTableViewDataSource *dataSource;
@property (nonatomic, assign) UITableViewStyle tableViewStyle; // 用來創建 tableView
- (instancetype)initWithStyle:(UITableViewStyle)style;
@end
為了確保子類創建了數據源，我們把這個方法定義到協議裏，並且定義為 required。
成果與目標
現在我們梳理壹下經過改造的 TableView 該怎麽用：
首先妳需要創建壹個繼承自 KtTableViewController 的視圖控制器，並且調用它的 initWithStyle 方法。
KTMainViewController *mainVC = [[KTMainViewController alloc] initWithStyle:UITableViewStylePlain];
在子類 VC 中實現 createDataSource 方法，實現數據源的綁定。
- (void)createDataSource {
self.dataSource = [[KtMainTableViewDataSource alloc] init]; // 這 壹步創建了數據源
}
在數據源中，需要指定 cell 的類型。
- (Class)tableView:(UITableView *)tableView cellClassForObject:(KtTableViewBaseItem *)object {
return [KtMainTableViewCell class];
}
在 Cell 中，需要通過解析數據，來更新 UI 並返回自己的高度。
+ (CGFloat)tableView:(UITableView *)tableView rowHeightForObject:(KtTableViewBaseItem *)object {
return 60;
}
// Demo 中沿用了父類的 setObject 方法。
還有什麽要優化的
到目前為止，我們實現了對 UITableView 以及相關協議、方法的封裝，使它更容易使用，避免了很多重復、無意義的代碼。
在使用時，我們需要創建壹個控制器，壹個數據源，壹個自定義 Cell，它們正好是基於 MVC 模式的。因此，可以說在封裝與解耦方面，我們已經做的相當好了，即使再花大力氣，也很難有明顯的提高。
但關於 UITableView 的討論遠遠沒有結束，我列出了以下需要解決的問題
在這種設計下，數據的回傳不夠方便，比如 cell 的給 C 發消息。
下拉刷新與上拉加載如何集成
網絡請求的發起，與解析數據如何集成
關於第壹個問題，其實是普通的 MVC 模式中 V 和 C 的交互問題，可以在 Cell（或者其他類） 中添加 weak 屬性達到直接持有的目的，也可以定義協議。
問題二和三是另壹大塊話題，網絡請求大家都會實現，但如何優雅的集成進框架，保證代碼的簡單和可拓展，就是壹個值得深入思考，研究的問題了。接下來我們就重點討論網絡請求。
為何創建網絡層
壹個 iOS
的網絡層框架該如何設計？這是壹個非常寬泛，也超出我能力範圍之外的問題。業內已有壹些優秀的，成熟的思路和解決方案，由於能力，角色所限，我決定從壹個
普通開發者而不是架構師的角度來說說，壹個普通的、簡單的網絡層該如何設計。我相信再復雜的架構，也是由簡單的設計演化而來的。
對於絕大多數小型應用來說，集成 AFNetworking 這樣的網絡請求框架就足以應付 99% 以上的需求了。但是隨著項目的擴大，或者用長遠的眼光來考慮，直接在 VC 中調用具體的網絡框架（下面以 AFNetworking 為例），至少存在以下問題：
壹旦日後 AFNetworking 停止維護，而且我們需要更換網絡框架，這個成本將無法想象。所有的 VC 都要改動代碼，而且絕大多數改動都是雷同的。
這樣的例子真實存在，比如我們的項目中就依然使用早已停止維護的 ASIHTTPRequest，可以預見，這個框架遲早要被替換。
現有的框架可能無法實現我們的需求。以 ASIHTTPRequest 為例，它的底層用 NSOperation
來表示每壹個網絡請求。眾所周知，壹個 NSOperation 的取消，並不是簡單調用 cancel
方法就可以的。在不修改源碼的前提下，壹旦它被放入隊列，其實是無法取消的。
有時候我們的需求僅僅是進行網絡請求，還會對這個請求進行各種自定義的拓展。比如我們可能要統計請求的發起和結束時間，從而計算網絡請求，數據解
析的步驟的耗時。有時候，我們希望設計壹個通用組件，並且支持由各個業務部門去自定義具體的規則。比如可能不同的部門，會為 HTTP
請求添加不同的頭部。
網絡請求還有可能有其他廣泛需要添加的需求，比如請求失敗時的彈窗，請求時的日誌記錄等等。
參考當前代碼（SHA-1:a55ef42）感受壹下沒有任何網絡層時的設計。
如何設計網絡層
其實解決方案非常簡單：
所有的計算機問題，都可以通過添加中間層來解決
讀者可以自行思考，為什麽添加中間層可以解決上述三個問題。
三大模塊
對於壹個網絡框架來說，我認為主要有三個方面值得去設計：
如何請求
如何回調
數據解析
壹個完整的網絡請求壹般由以上三個模塊組成，我們逐壹分析每個模塊實現時的註意事項：
發起請求
發起請求時，壹般有兩種思路，第壹種是把所有要配置的參數寫到同壹個方法中，借用 與時俱進，HTTP/2下的iOS網絡層架構設計 壹文中的代碼表示：
+ (void)networkTransferWithURLString:(NSString *)urlString
andParameters:(NSDictionary *)parameters
isPOST:(BOOL)isPost
transferType:(NETWORK_TRANSFER_TYPE)transferType
andSuccessHandler:(void (^)(id responseObject))successHandler
andFailureHandler:(void (^)(NSError *error))failureHandler {
// 封裝AFN
}
這種寫法的好處在於所有參數壹目了然，而且簡單易用，每次都調用這個方法即可。但是缺點也很明顯，隨著參數和調用次數的增多，網絡請求的代碼很快多到爆炸。
另壹組方法則是將 API 設置成壹個對象，把要傳入的參數作為這個對象的屬性。在發起請求時，只要設置好對象的相關屬性，然後調用壹個簡單的方法即可。
@interface DRDBaseAPI : NSObject
@property (nonatomic, copy, nullable) NSString *baseUrl;
@property (nonatomic, copy, nullable) void (^apiCompletionHandler)(_Nonnull id responseObject, NSError * _Nullable error);
- (void)start;
- (void)cancel;
...
@end
根據前文提到的 Model 和 Item 的概念，那麽應該可以想到：這個用於訪問網絡的 API 對象，其實是作為 Model 的壹個屬性。
Model 負責對外暴露必要的屬性和方法，而具體的網絡請求則由 API 對象完成，同時 Model 也應該持有真正用來存儲數據的 Item。
如何回調
壹次網絡請求的返回結果應該是壹個 JSON 格式的字符串，通過系統的或者壹些開源框架可以將它轉換成字典。
接下來我們需要使用 runtime 相關的方法，將字典轉換成 Item 對象。
最後，Model 需要將這個 Item 賦值給自己的屬性，從而完成整個網絡請求。
如果從全局角度來說，我們還需要壹個 Model 請求完成的回調，這樣 VC 才能有機會做相應的處理。
考慮到 Block 和 Delegate 的優缺點，我們選擇用 Block 來完成回調。
數據解析
這壹部分主要是利用 runtime 將字典轉換成 Item，它的實現並不算難，但是如何隱藏好實現細節，使上層業務不用過多關心，則是我們需要考慮的問題。
我們可以定義壹個基類的 Item，並且為它定義壹個 parseData 函數：
// KtBaseItem.m
- (void)parseData:(NSDictionary *)data {
// 解析 data 這個字典，為自己的屬性賦值
// 具體的實現請見後面的文章
}