前言
去年做了一個小組件，前些時間考慮到項目中可能會大規(guī)模實施，完善簡化后新開了一個 repo: YBHandyList 。
有些朋友拋出了 nimbus、IGListKit 等業(yè)界應用很廣的庫，前些時間網(wǎng)易工程師也推出了 M80TableViewComponent。理論上這些組件的原理大同小異，雖然它們各有優(yōu)勢，但卻不太能滿足筆者對架構清晰度的要求。
本文分析 YBHandyList 的應用價值，希望能解開一些朋友的疑惑。
業(yè)務痛點
iOS 界面開發(fā)中 UITableView / UICollectionView 的出場率極高，它們都是使用代理方法配置數(shù)據(jù)源，雖然這樣的設計理念符合了單一職責原則，但在列表變得復雜時代理方法的處理將變得力不從心：
- 同一個 Cell / Header / Footer 處理邏輯分散在各個代理方法中，不便于管理。
- 當列表數(shù)據(jù)動態(tài)變化時，每一個代理方法里的判斷邏輯都將變得復雜，且這些邏輯很可能會相互關聯(lián)。
顯然，在這樣的場景下將是維護的災難，特別是當你接手別人的代碼發(fā)現(xiàn)每個 UITableView 代理方法里都有幾十個if-else，它們?nèi)硕鄤荼姡磕悴桓覄铀鼈內(nèi)魏我粋€。
由此可見，若想維護性高需要解開每一個 Cell 之間的邏輯耦合，也就是通常意義的模塊化，由此才能更輕易的實現(xiàn)動態(tài)化。解決方案其實很簡單，只需要一個中間類，將分散的配置集中起來（在代理方法里取這個中間類的對應值）：
@interface Config : NSObject
@property (nonatomic, assign) CGFloat height;
@property (nonatomic, strong) Class cls;
@property (nonatomic, strong) id model;
@end
然而對于業(yè)務工程師來說，每次寫這樣的代碼都意味著時間成本，所以制作一個基礎組件是很有必要的，它需要滿足以下特性：
- 模塊化配置 Cell / Header / Footer。
- 更容易實施列表動態(tài)化。
- 能拓展原生能實現(xiàn)的所有場景。
為此，YBHandyList 應運而生，它足夠簡單以至于從設計到編碼基本就花了一天時間。
YBHandyList 的優(yōu)勢
原理：
代碼簡單輕量
YBHandyList 保留最小功能，代碼量很少，核心思路就一句話：將 UITableView / UICollectionView 的數(shù)據(jù)源從代理方法配置轉(zhuǎn)化為數(shù)組配置。
在其它庫當中可以看到高度緩存、訪問迭代器等邏輯，筆者認為這樣的基礎設施不應該侵入過多業(yè)務，它們本應該是業(yè)務關注的邏輯，這樣的語法糖只能在簡單場景下少寫些代碼，當業(yè)務變得復雜時往往這樣的優(yōu)勢就不存在了。
YBHandyList 的語法糖非常收斂，簡單的一個延展，你甚至可以選擇不使用語法糖，直接使用代理實現(xiàn)類。
由此，新手工程師也能對實施代碼充滿信心。
業(yè)務侵入性低
YBHandyList 采用 IOP 設計，最大限度的降低了業(yè)務侵入性，只需要在 Cell / Header / Footer 中實現(xiàn)幾個代理方法就行了。
去基類化設計讓數(shù)據(jù)流動過程更加純粹，不需要考慮父類做了什么，沒做什么。在老業(yè)務中可能存在類似BaseTableViewCell 的東西，YBHandyList 也能優(yōu)雅的接入，這種場景下繼承的設計范式將力不從心。
這種架構規(guī)范類組件接入的成本非常重要，而舍棄的成本也不容忽視，由于 IOP 天然的優(yōu)勢，YBHandyList 結構代碼的舍棄將輕而易舉，不拖泥帶水。
直觀的動態(tài)化控制
構建界面只需要關注所有id<Config>在數(shù)據(jù)源數(shù)組中的順序，就像搭積木一樣拼接起來，數(shù)組中的順序就是對應 Cell 在界面中的顯示順序，由此就能通過改變數(shù)據(jù)源數(shù)組的順序輕易的實現(xiàn)動態(tài)化控制。
在 MVVM 架構中實施
YBHandyList 的設計方式讓它在各種架構中都能無障礙實施，下面以 MVVM 舉例（僅說明 UITableViewCell 的實施，具體可以看 DEMO）：
可以看到，Cell 與 UITableView 非直接耦合，所以若需要將 Cell 的事件傳遞出來最好通過 Cell 的 ViewModel，ViewModel 作為連接 Cell 與外界的橋梁。
Cell 的 ViewModel 也可以在主 ViewModel 中構建，這樣 Controller 中就不用導入這些類，不過當 Cell 的 ViewModel 需要將事件傳遞到 Controller 時，就會需要一些膠水代碼通過主 ViewModel 間接傳遞。
數(shù)據(jù)綁定并非必須做的事情，你可以用 RAC，或者另外一個選擇：EasyReact，可以參考筆者的文章：美團 EasyReact 源碼剖析：圖論與響應式編程。
更安全和優(yōu)雅的復用
很多時候，我們會將具體業(yè)務的處理邏輯放 Cell 中或者其 ViewModel 中，那么它們就很難復用，因為復用是建立在無具體業(yè)務侵入的前提下。
實際上只需要將具體業(yè)務的處理邏輯抽離出來，處理過后再放在 ViewModel 中，Cell 拿到 ViewModel 再進行具體業(yè)務無關的界面刷新。如此，ViewModel 將可以在任何地方復用。
使用 YBHandyList 后，ViewModel 把 Cell 與外部業(yè)務解開耦合，只把需要暴露的東西寫在ViewModel .h中，外部業(yè)務無需導入 Cell 便能通過 ViewModel 直接復用，更加的安全。
能拓展原生支持的場景
一個基礎設施最怕的就是不能滿足所有場景的情況下還封閉了拓展的入口。YBHandyList 通過繼承默認代理實現(xiàn)類就能拓展實現(xiàn)其它的 UITableView / UICollectionView 代理方法。
這看起來有些繁瑣，使用多代理技術能避免額外的創(chuàng)建代理實現(xiàn)類，但這樣會導致代碼不再簡單和透明。換個角度想，代理實現(xiàn)類中將大量復雜邏輯處理過后，僅僅回調(diào)給外部業(yè)務一個簡單的方法，達到為外部模塊瘦身的目的。
后語
筆者一直偏好簡潔的代碼設計，讓核心功能最小化實現(xiàn)，當它無法覆蓋所有的場景時一定要有原生拓展能力。語法糖的主要意義是減少使用者的思考成本而不單單是為了少寫兩句代碼，它不應該侵入功能收斂的核心代碼。要做好這一切，就一定要透過現(xiàn)象看清問題的本質(zhì)。
