一、传统方式的弊端
UITableView是出场率极高的视图组件，开发者通过实现 <UITableViewDataSource>和<UITableViewDelegate>协议方法来配置布局逻辑，面向协议设计模式在苹果的代码设计中很常见，它能适应大部分的业务场景且足够灵活。
UITableView相关的协议方法充分体现了单一职责原则，这种方式优点很多，比如某一时刻组件只需要关心当前需要的数据，避免了多余的计算，同时也可以让数据及时释放减小内存峰值。
然而当某一个界面结构比较复杂多元且展示顺序可动态变化的时候，开发者往往需要写大量的if/else/else if或 switch分支语句来区分不同section/row的视图类型及其布局，由于 UITableView相关协议方法的职责单一性，这种分支语句会重复出现在多个协议方法里面。
显然这种场景下，UITableView变得不那么优雅。
二、常规优化思路
理所当然的，大家很容易想到使用一个中间类来将布局一个 Cell 分散的数据集中起来管理：
@interface CellLayout : NSObject@property (nonatomic, strong) Class cellClass;@property (nonatomic, assign) CGFloat cellHeight;@property (nonatomic, strong) AnyModel *cellModel;...@end
然后在UITableView各个协议方法里从 NSArray<CellLayout *> layoutArray;数组中拿到CellLayout对象配置就行了，如此，开发者只需要关心如何构建 layoutArray数组，避免了在协议方法中写过多的分支语句。
这种思路就做了两件事：
-
提供一个包含某个 Cell 所有布局信息的中间类。
-
在中间类确定的情况下，
和协议方法返回值只需要依据对应中间类的某个属性，简洁清晰。
笔者思考过后，花了些时间做了一个小组件 (https://github.com/indulgeIn/YBHandyTableView)，它能让你轻松的实现这种优化方案，核心操作就是用数组来替代协议方法为UITableView配置数据。
当然，这么做有它的局限性，后文再来分析。
三、组件架构设计
经过前面的分析，组件要做的事情有两个，一个是设计一个中间类，一个是封装<UITableViewDataSource>和 <UITableViewDelegate>协议方法的实现。
核心思路
按照常规的思路，可能会想到设计一个通用的中间类，就像之前说的CellLayout，然后利用继承的特性来为 CellLayout添加额外的属性。这样确实能达到目的，不过这样带来了较为严重的耦合，需要开发者一开始就知道他必须写一个类来继承自你的CellLayout，若本身业务中需要继承另外一个类就很蛋疼了（毕竟 OC 不支持多继承）；再者，若某一天想要剔除这种方案可能会很麻烦， CellLayout设计得越臃肿、包含的业务越多将越难剥离。
并且，一个CellLayout是解决不了问题的，因为配置 UITableView可能需要UITableViewCell的一些数据，也需要一些通用的方法来告知 UITableViewCell何时配置数据刷新UI，也就意味着按照这种逻辑，还需要写一个BaseTableViewCell……
显然，这种方式并不优雅，也违背了依赖倒置原则。
笔者的做法是将这个“中间类”抽象出来，作为两个协议：YBHTCellProtocol和 YBHTCellConfigProtocol，这两个协议包含了布局UITableView所需的数据，当然可以结合自己的业务扩充这两个协议。 YBHTCellProtocol由自定义的UITableViewCell来实现； YBHTCellConfigProtocol随意开发者用什么类来实现，通常情况下，使用包含UITableViewCell所需数据的
Model来实现是最快捷的做法（可看Demo中的使用案例）。
保证深度定制性
考虑到一个问题，UITableView相关协议方法非常多，若为 YBHTCellProtocol和YBHTCellConfigProtocol拓展所有的配置将会需要大量的代码，可能有些得不偿失。
所以笔者使用多代理 (YBHandyTableViewProxy) 来保证组件使用方深度定制的需求，也是为了避免某些特殊情况下，使用该组件的业务模块能快速的拓展之前没有的功能：
- (
void)ybht_addDelegate:(
id<
UITableViewDelegate>)delegate;
- (
void)ybht_addDataSource:(
id<
UITableViewDataSource>)dataSource;
当然这样做会有隐患，所以建议读者朋友若想使用该组件先了解它的原理，该组件的代码不多也不高深，相信只要感兴趣的朋友能很快理解。
四、组件的弊端
组件的配置方式很简单：
NSArray<id<YBHTCellConfigProtocol>> tmpArr = ...;[anyTableView.ybht_rowArray addObjectsFromArray:tmpArr];[anyTableView reloadData];
正如代码所见，需要传入的是实现YBHTCellConfigProtocol协议的实例，同时需要对应的 UITableViewCell实现YBHTCellProtocol协议（可对比 UML 类图）。
取个例子，若你在UIViewController里面写了一个 UITableView，然后使用该组件配置数据，可以明确的是组件将<UITableViewDataSource>和 <UITableViewDelegate>协议封装起来，UIViewController和你定制的那些 UITableViewCell已经没有了耦合，也就意味着，它们之间的交互将不能直接进行。
那么，它们如何间接的交互呢？
-
YBHandyTableViewIMP是组件实现和协议的类，那么将UIViewController对象传入到该类就能实现与UITableViewCell的交互，但是由于YBHandyTableViewIMP和UITableViewCell不直接依赖而是都依赖于YBHTCellProtocol协议，这为定制性的交互带来了困难。 -
从另一个方面思考问题，从组件的使用方法可知，
UIViewController和id之间是有关联的，而id与UITableViewCell是有关联的，所以可以通过id将UIViewController传递到UITableViewCell中，然后进行交互。 -
基于响应链的传递路径来拦截事件。这种方式比较巧，但是却始终感觉不是那么稳妥，它的好处是处理
UITableViewCell的交互事件完全可以不经过该组件就能完成。
最后，笔者建议使用第二种方式。
不过不管哪种方式来说都不太优雅了，在业务开发中应该多考虑一下，UITableViewCell中会不会有大量的事件需要传递到最外层的业务，比如跳转界面、网络请求等就可以直接在 UITableViewCell里面调用。若大量的交互是必然的（或者说是为了满足业务架构规范），那就放弃“偷懒”，专门设计一个适合业务的方式吧。
五、结语
本文是笔者做的一个小实践的思路分享，需要明白的是，一个代码设计并非能满足所有的业务，特别是这种和具体业务紧密相连的组件。在一开始笔者还满怀希望，觉得这个组件的场景很大，后来发现还是有局限性。
组件总是会让粒度变大，当你追求更小粒度的时候你会发现：我去，好像这个组件没有了意义😂。
设计有取舍，没有万能的方案。
GitHub 地址：YBHandyTableView ( https://github.com/indulgeIn/YBHandyTableView)
推荐阅读
在看就点点吧
