前言
去年做了一個小組件压汪，前些時間考慮到項目中可能會大規(guī)模實施，完善簡化后新開了一個 repo: YBHandyList 。
有些朋友拋出了 nimbus糊昙、IGListKit 等業(yè)界應(yīng)用很廣的庫费奸，前些時間網(wǎng)易工程師也推出了 M80TableViewComponent弥激。理論上這些組件的原理大同小異，雖然它們各有優(yōu)勢愿阐，但卻不太能滿足筆者對架構(gòu)清晰度的要求微服。
本文分析 YBHandyList 的應(yīng)用價值，希望能解開一些朋友的疑惑缨历。
業(yè)務(wù)痛點
iOS 界面開發(fā)中 UITableView / UICollectionView 的出場率極高以蕴，它們都是使用代理方法配置數(shù)據(jù)源糙麦，雖然這樣的設(shè)計理念符合了單一職責(zé)原則，但在列表變得復(fù)雜時代理方法的處理將變得力不從心：
- 同一個 Cell / Header / Footer 處理邏輯分散在各個代理方法中丛肮，不便于管理赡磅。
- 當列表數(shù)據(jù)動態(tài)變化時，每一個代理方法里的判斷邏輯都將變得復(fù)雜宝与，且這些邏輯很可能會相互關(guān)聯(lián)焚廊。
顯然，在這樣的場景下將是維護的災(zāi)難习劫，特別是當你接手別人的代碼發(fā)現(xiàn)每個 UITableView 代理方法里都有幾十個if-else节值，它們?nèi)硕鄤荼姡磕悴桓覄铀鼈內(nèi)魏我粋€榜聂。
由此可見搞疗，若想維護性高需要解開每一個 Cell 之間的邏輯耦合，也就是通常意義的模塊化须肆，由此才能更輕易的實現(xiàn)動態(tài)化匿乃。解決方案其實很簡單，只需要一個中間類豌汇，將分散的配置集中起來（在代理方法里取這個中間類的對應(yīng)值）：
@interface Config : NSObject
@property (nonatomic, assign) CGFloat height;
@property (nonatomic, strong) Class cls;
@property (nonatomic, strong) id model;
@end
然而對于業(yè)務(wù)工程師來說幢炸，每次寫這樣的代碼都意味著時間成本，所以制作一個基礎(chǔ)組件是很有必要的拒贱，它需要滿足以下特性：
- 模塊化配置 Cell / Header / Footer宛徊。
- 更容易實施列表動態(tài)化。
- 能拓展原生能實現(xiàn)的所有場景逻澳。
為此闸天，YBHandyList 應(yīng)運而生，它足夠簡單以至于從設(shè)計到編碼基本就花了一天時間斜做。
YBHandyList 的優(yōu)勢
原理：
代碼簡單輕量
YBHandyList 保留最小功能苞氮，代碼量很少，核心思路就一句話：將 UITableView / UICollectionView 的數(shù)據(jù)源從代理方法配置轉(zhuǎn)化為數(shù)組配置瓤逼。
在其它庫當中可以看到高度緩存笼吟、訪問迭代器等邏輯，筆者認為這樣的基礎(chǔ)設(shè)施不應(yīng)該侵入過多業(yè)務(wù)霸旗，它們本應(yīng)該是業(yè)務(wù)關(guān)注的邏輯贷帮，這樣的語法糖只能在簡單場景下少寫些代碼，當業(yè)務(wù)變得復(fù)雜時往往這樣的優(yōu)勢就不存在了诱告。
YBHandyList 的語法糖非常收斂撵枢，簡單的一個延展，你甚至可以選擇不使用語法糖，直接使用代理實現(xiàn)類诲侮。
由此镀虐，新手工程師也能對實施代碼充滿信心。
業(yè)務(wù)侵入性低
YBHandyList 采用 IOP 設(shè)計沟绪，最大限度的降低了業(yè)務(wù)侵入性刮便，只需要在 Cell / Header / Footer 中實現(xiàn)幾個代理方法就行了。
去基類化設(shè)計讓數(shù)據(jù)流動過程更加純粹绽慈，不需要考慮父類做了什么恨旱，沒做什么。在老業(yè)務(wù)中可能存在類似BaseTableViewCell 的東西坝疼，YBHandyList 也能優(yōu)雅的接入搜贤，這種場景下繼承的設(shè)計范式將力不從心。
這種架構(gòu)規(guī)范類組件接入的成本非常重要钝凶，而舍棄的成本也不容忽視仪芒，由于 IOP 天然的優(yōu)勢，YBHandyList 結(jié)構(gòu)代碼的舍棄將輕而易舉耕陷，不拖泥帶水掂名。
直觀的動態(tài)化控制
構(gòu)建界面只需要關(guān)注所有id<Config>在數(shù)據(jù)源數(shù)組中的順序，就像搭積木一樣拼接起來哟沫，數(shù)組中的順序就是對應(yīng) Cell 在界面中的顯示順序饺蔑，由此就能通過改變數(shù)據(jù)源數(shù)組的順序輕易的實現(xiàn)動態(tài)化控制。
在 MVVM 架構(gòu)中實施
YBHandyList 的設(shè)計方式讓它在各種架構(gòu)中都能無障礙實施嗜诀，下面以 MVVM 舉例（僅說明 UITableViewCell 的實施猾警，具體可以看 DEMO）：
可以看到，Cell 與 UITableView 非直接耦合隆敢，所以若需要將 Cell 的事件傳遞出來最好通過 Cell 的 ViewModel发皿，ViewModel 作為連接 Cell 與外界的橋梁。
Cell 的 ViewModel 也可以在主 ViewModel 中構(gòu)建筑公，這樣 Controller 中就不用導(dǎo)入這些類雳窟，不過當 Cell 的 ViewModel 需要將事件傳遞到 Controller 時，就會需要一些膠水代碼通過主 ViewModel 間接傳遞匣屡。
數(shù)據(jù)綁定并非必須做的事情，你可以用 RAC拇涤，或者另外一個選擇：EasyReact捣作，可以參考筆者的文章：美團 EasyReact 源碼剖析：圖論與響應(yīng)式編程。
更安全和優(yōu)雅的復(fù)用
很多時候鹅士，我們會將具體業(yè)務(wù)的處理邏輯放 Cell 中或者其 ViewModel 中券躁，那么它們就很難復(fù)用，因為復(fù)用是建立在無具體業(yè)務(wù)侵入的前提下。
實際上只需要將具體業(yè)務(wù)的處理邏輯抽離出來也拜，處理過后再放在 ViewModel 中以舒，Cell 拿到 ViewModel 再進行具體業(yè)務(wù)無關(guān)的界面刷新。如此慢哈，ViewModel 將可以在任何地方復(fù)用蔓钟。
使用 YBHandyList 后，ViewModel 把 Cell 與外部業(yè)務(wù)解開耦合卵贱，只把需要暴露的東西寫在ViewModel .h中滥沫，外部業(yè)務(wù)無需導(dǎo)入 Cell 便能通過 ViewModel 直接復(fù)用，更加的安全键俱。
能拓展原生支持的場景
一個基礎(chǔ)設(shè)施最怕的就是不能滿足所有場景的情況下還封閉了拓展的入口兰绣。YBHandyList 通過繼承默認代理實現(xiàn)類就能拓展實現(xiàn)其它的 UITableView / UICollectionView 代理方法。
這看起來有些繁瑣编振，使用多代理技術(shù)能避免額外的創(chuàng)建代理實現(xiàn)類缀辩，但這樣會導(dǎo)致代碼不再簡單和透明。換個角度想踪央，代理實現(xiàn)類中將大量復(fù)雜邏輯處理過后雌澄，僅僅回調(diào)給外部業(yè)務(wù)一個簡單的方法，達到為外部模塊瘦身的目的杯瞻。
后語
筆者一直偏好簡潔的代碼設(shè)計镐牺，讓核心功能最小化實現(xiàn)，當它無法覆蓋所有的場景時一定要有原生拓展能力魁莉。語法糖的主要意義是減少使用者的思考成本而不單單是為了少寫兩句代碼睬涧，它不應(yīng)該侵入功能收斂的核心代碼。要做好這一切旗唁，就一定要透過現(xiàn)象看清問題的本質(zhì)畦浓。
