阅读本文需要对ReactiveCocoa足够了解，也可以参阅图解ReactiveCocoa基本函数（http://www.jianshu.com/p/38d39923ee81）
Cocoa Touch Framework无疑是一个很好的框架，特别是对动画的支持，在我接触过的框架中可能是最好的（当然我接触的框架可能比较少），但是就UITableView来说确实存在很多吐槽点，从我个人理解的角度做些分析，尝试去解决这些吐槽点，并给到的解决方案。
UITableView枚举滥用
枚举从来都是为了可扩展而存在的，UITableView中对UITableViewStyle的使用堪称滥用，先看看这个枚举的定义，枚举项的命名不够直观，源码的注释也得不到有效信息，
再看看如下文档的说明，基本明确了设计者的本意，UITableViewStyle想要区分的是页眉或页脚（section headers or footers）是否浮动，接下来做个剖析：
UITableView的初始化函数
UITableViewStyle作为初始化函数的参数的不合理性，大多数的UIView及其子类都是一样风格的初始化函数，到了UITableView这里就显得有点另类，设计者将 UITableViewStyle放到初始化函数中作为参数，无非就是不希望style在UITableView初始化之后被改变，可能原因是UITableView滑动的过程中style被改变了，不管之前是否存在浮动的页眉或页脚，改变之后对UI的呈现可能是比较突兀的，另外这种变更可能并没有实际意义；
UITableViewStyle的存在不合理，当一个枚举只存在两个选项时，很多时候会考虑使用BOOL来表示，可读性也不差，比如这里用isSectionGrouped，可能时不需要看注视或者文档就可以理解了；
UITableViewStylePlain的命名不合理，我们知道UITableView总是会分section，
Plain从其语义和StoryBoard默认值的显示可以联想UITableViewStylePlain可能是想表示只有一个section的情况，那么所谓的页眉或页脚是否浮动其实就没有太大意义，如果页眉或页脚不需要浮动其实就是一个Cell了，因为最终效果都是一样的，反过来假设需要多个section，但是页眉或页脚都不需要浮动，那么这些页眉或页脚其实用Cell来表示是不是更好呢！
综上得出结论：UITableViewStyle是不该用。
UITableViewCell枚举乱用
UITableViewCell存在好几个枚举的乱用，乱用表示不该用的时候用了。
UITableViewCellStyle的乱用
UITableViewCell的初始化方法中同样也带上了UITableViewCellStyle，先看代码
如果说UITableView设计者觉得就只存在两种style，那么UITableViewCell设计中加入UITableViewCellStyle就显得完全是乱用了。一样的道理，枚举从来就不是为了扩展而存在，UITableViewCell做为cell的基类，扩展是必须的，不可能所有的cell都长的跟UITableViewCellStyle中定义的几个枚举项所分类的完全一样，所以这个设计是有多恶心啊。
再看看UITableViewCellStyle的各个枚举项的命名，简直是残暴啊，UITableViewCellStyleValue1，UITableViewCellStyleValue2这些是什么鬼哦，再看看注释，分别说明Used in Settings和Used in Phone/Contacts，这就很明显了，这些实现完全就是系统组件用到了这样的实现，然后直接做为api开放出来的，并没有做很好的抽象，在初始化函数中加入UITableViewCellStyle，污染了初始化函数，限制了扩展，每每在写一个UITableViewCell的子类时，总是有一种莫名的哀伤，UITableViewCellStyle做为参数存在唯一的作用就是多写了点代码，然后没有任何意义。这些cell style所表示的cell完全应该通过子类化来实现的，所以UITableViewCellStyle的乱用是有点惨不忍睹的。
UITableViewCellSeparatorStyle的乱用
怎么说也不应该存在这样一个枚举，CellSeparatorStyle这里针对不同的UITableViewStyle而设计的，不管是何种style，应该只需要isShowCellSeparatorLine这样一个BOOL值表示是否需要显示边框，如果是UITableViewStyleGrouped这种style，可能需要额外的一个isCellSeparatorLineEtched，如果根据前面的假设，页眉或页脚都是默认浮动的话，这样设计是很合理的。
当一个枚举各项的命名过于诡异时，这个枚举的存在实际上是要好好考虑下的，所以UITableViewCellSeparatorStyle也是典型的乱用。
UITableViewCell对以下枚举的使用也是有待商榷的
UITableViewCellSelectionStyle想表示cell选中的样式，这里大概是通过这种方式来提高几种默认值，因为CellSelectionStyle还是可以定制的,但是UITableViewCellSelectionStyleDefault放在最后UITableViewCellSelectionStyleNone放在最开始，到底谁是default哦；
UITableViewCellFocusStyle这个枚举的存在难道仅仅是为了无病呻吟吗？
UITableView委托乱用
UITableViewDelegate，UITableViewDataSource，包括刚引入的UITableViewDataSourcePrefetching，这几个delegate的设计好像是缺少了些设计，更像是为了解决问题而写代码，作为一个基础框架，实在是不可取的。
UITableViewDelegate设计之重
这几个委托函数，都是与Cell、页眉、页脚相关的，但是全都集中在UITableViewDelegate这个委托中，且命名都是类似，当一个protocol在定义时存在过多的@optional委托函数时，这个protocol的设计本身就是不合理的，应该拆分成更细的protocol，我们应该时在必要的时候选择相应的protocol，而不是实现存在的@optional委托函数，然后UITableViewDelegate这个protocol本身所有的委托函数都是@optional，这是真的不合理，如果是我们来设计Cell、页眉、页脚实际上都是应该UIView，且存在诸多共同点（参考UICollectionView的设计，Cell、页眉、页脚就存在一个共同的基类UICollectionReusableView），应该设计一个UIReusableView，（UICollectionReusableView也可以不需要了）其中存在如下方法，这些方法可以在子类中重写
且应该设计一个UIReusableViewDelegate，其包括如下委托函数
UIReusableView存在UIReusableViewDelegate的一个delegate，前面所提到的那六个委托函数，实际上应该在Cell、页眉、页脚各自需要的时候实现UIReusableViewDelegate。
综上，UITableViewDelegate实际上是太重了。
UITableViewDelegate职责之乱
下面这些委托函数，实际上应该存在UITableViewDataSource中。页眉、页脚的数据源跟cell的数据源应该是平等的存在，不应该是说不常用了，我就放到UITableViewDelegate中，本来就应该放在UITableViewDataSource，不必须用的可以optional修饰下也还说得过去。
UITableViewDataSource设计之重
经过前面的梳理，那么UITableViewDataSource中应该包括以下这些函数
跟前面提到UITableViewDelegate设计之重一个道理，Cell、页眉、页脚的DataSource也是应该分开的，在需要的时候实现对应的DataSource，需要定义额外的一个枚举UIReusableViewType
然后对页眉、页脚就有UIReusableViewDataSource，其中的委托函数如下：
单独的针对cell，有UITableViewCellDataSource，其中的委托函数如下：
至于UITableViewDataSourcePrefetching就不应该出现，为了优化滚动帧率，拆东墙补西墙之举。从开发者的角度，最简单的做法就是把整个的数据源给到，剩下的就应该是UITableView自身去实现了，数据都有了，想要什么预加载都是框架自身的事情了，减少对开发者的依赖，更是减少api的耦合度，对外暴露的接口越多越不好。
改造之路在何方？
前面在吐槽的时候，每每会给出自认为更合理的设计，然而并没有什么卵用，既有代码是无法修改的，那改造之路又在何方呢？不能改变既有代码，那么只能是将这么东西尽可能的封装起来，Objective-C语言还提供了一个蛮有意思的编译期常量NS_UNAVAILABLE，可以在编译期禁用父类的方法，算是不完美中的完全吧，我们可以禁用掉一些不合理的类成员，来达到一个比较好的封装效果。
UITableView枚举滥用的解决
UITableView可以禁用被枚举污染的初始化函数，重写默认的initWithFrame初始化函数并默认设style为UITableViewStyleGrouped，参考类 LPDTableView暂时并没有重写初始化函数，目前认为无伤大雅。
UITableViewCell枚举乱用的解决
UITableViewCell无法禁用被枚举污染的初始化函数，因为重用时会调用到，参考类 LPDTableViewCell，选择无视UITableViewCellStyle，并将已存在的几种cellStyle都扩展成对应的子类，LPDTableViewDefaultCell，LPDTableViewValue1Cell，LPDTableViewValue2Cell，LPDTableViewSubtitleCell命名还是保留一致，毕竟大家都已经习惯了这种丑。
UITableView委托乱用的解决
既然无法改造既有的UITableView，可以从另外一个侧面来解决。
UITableView如何数据驱动
引入MVVM的思想，为UITableView添加对应的ViewModel，有了ViewModel，则可以引入数据驱动的方式，当我们需要为Cell、页眉、页脚提供DataSource时，只需要调用LPDTableViewModelProtocl中的方法就好了，接口的粒度已经比较细了，但可能不是最合理的组合，相关的函数都在下面：
UITableView委托转RACSignal
引入ReactiveCocoa中的RACSignal，将UITableViewDelegate中的委函数都转成信号，当我们需要实现某一个委托函数，只需要订阅对应的RACSignal即可，不订阅没有任何副作用。
Cell、页眉、页脚也存在相应的ViewModel
Cell、页眉、页脚跟其ViewModel之间需要遵守约定好的命名规则，如此会自动匹配。另外Cell、页眉、页脚默认都是重用的，同一类型reuseIdentifier一样，重用相关的函数就都在 LPDTableViewFactory。这个类中了当我们关心DataSource或者Delegate时，我们只需要跟对应的ViewModel交互即可，将Cell、页眉、页脚解耦合。
LPDTableSectionViewModelProtocol
这个protocol的实现类LPDTableSectionViewModel，只是在ViewModel层抽象出来，这样才好完善ViewModel层的实现，并不存在对应的SectionView。
关于height
cell，header，footer的viewmodel中都有对应的height字段，需要根据viewmodel的model字段在bindingTo:viewModel函数中设置height值，可以针对model做height的缓存。
改造之后的例子
加载tableview的数据
添加一个cell
批量添加cell
删除一个cell
Cell的didSelectRowAtIndexPathSignal
具体请下载lpd-tableview-kit（https://github.com/LPD-iOS/lpd-tableview-kit），看看其中的demo。