见过不少人这样书写过tableViewDelegate的方法
func numberOfSections(in tableView: UITableView) -> Int {
return 2
}
func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
return 10
}
func tableView(_ tableView: UITableView, heightForRowAt indexPath: IndexPath) -> CGFloat {
if indexPath.section == 0 return 50
if indexPath.section == 1 return 80
.......还有针对不同 indexPath.row 返回的
}
func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
//重点来了,就是这里
if indexPath.section == 0 {
if 需要创建A类型的
/*
create Acell
return Acell
*/
if 需要创建B类型的
/*
create Bcell
return Bcell
*/
if 需要创建C类型的
/*
create Ccell
return Ccell
*/
}else{
....
....
....
}
}
或者是根据某些条件，如判断dataSource中对应index的内容是什么，然后再去创建cell，不管怎样，这种写法的后果就是。。。看了想吐。。。~~！
当然，我也经历过让别人吐这个阶段，没办法，虽然在意过但那时候没觉得应该优化，觉得就应该这么写，谁让产品设计的页面这么复杂，后期维护困难时产品设计的问题。。。。
入职现在的公司后，发现现有小伙伴们正在致力于优化代码，其中的一个方向就是提高代码可读性。。。。这就不可避免的要好好琢磨一下如何优化各种 if -else -if、眼花缭乱的 switch-case代码了。。。。。
经过一系列的尝试，我这里逐渐摸索到了一个自我感觉比较良好的方式，并利用到平时的OC开发中；想在，由于项目需要，正在帮另一个项目组搞Swift开发，于是就想着是不是应该把这个好东西带到Swift开发中，经过一番实践（没经历过系统的swift学习，现在开发都是直接凭OC的经验来的，或者干脆百度copy，所以这个实践的过程特别闹心）终于成功实施了。。。
这套方案的核心思想是：
1、利用ViewModel分担一部分TableViewDelegate方法
2、数据解析阶段直接封装好不同的ViewModel
3、建立协议，tableView 的 delegator直接通过协议向viewModel索要cell实例
一、建立Protocol
import Foundation
@objc protocol WGVMCellProtocol {
//update cell
@objc optional func wg_hl_updateCellInfo(viewModel:AnyObject)
//create a viewModel
@objc optional static func wg_hl_creatViewModel(model:AnyObject) -> (AnyObject)
//create a cell
@objc optional func wg_hl_getSpecificCell(tableView:AnyObject) -> (AnyObject)
//get cell height
@objc optional func wg_hl_getSpecificCellHeight()->(CGFloat)
}
wg_hl_updateCellInfo 是提供给Cell的方法，传入一个ViewModel，然后去刷新Cell
wg_hl_creatViewModel 提供给数据解析阶段，这个方法可有可无，传入一个Model，然后返回一个ViewModel
wg_hl_getSpecificCell、wg_hl_getSpecificCellHeight，这两个方法也是提供给ViewModel去实现的，目的是让不同的ViewModel去实现两个代理方法，返回特定的Cell以及Cell的高度
二、创建Cell，并实现部分协议
假设现有3中类型的Cell，一种是理财产品类型的条目，一种是淘宝上的一款商品的条目，另一种是微博帖子的条目
创建、布局什么的就不说了，只说一下这几个Cell必须实现的protocol方法
extension 理财Cell:WGVMCellProtocol{
func wg_hl_updateCellInfo(viewModel: AnyObject) {
}
extension 商品Cell:WGVMCellProtocol{
func wg_hl_updateCellInfo(viewModel: AnyObject) {
}
extension 帖子Cell:WGVMCellProtocol{
func wg_hl_updateCellInfo(viewModel: AnyObject) {
}
就是这样
三、创建不同的ViewModel
同上，只贴上三个protocol方法的实现
extension 理财ViewModel:WGPurchaseProtocol{
//创建viewModel
static func wgp_creatViewModel(model: WGRechargeListModel) -> (AnyObject) {
let viewModel = WGPMyGoldCoinsViewModel.init()
.....平时我写的时候这里还有好多操作
return viewModel
}
//create a cell
func wgp_getSpecificCell(tableView:AnyObject) -> (AnyObject){
//有关于各种复用、判空新建的逻辑我写到Cell里面了，这里直接调用拿返回
let cell = WGPMyGoldCoinsTableViewCell.createMyGoldCoinsCell(tableView: tableView as! UITableView)
return cell
}
//get cell height
func wgp_getSpecificCellHeight()->(CGFloat){
return 100
}
}
.......同理，其余两个商品和帖子类型的ViewModel也需要实现这三个protocol方法
四、数据解析时，创建不同的ViewModel，并放入dataSource中提供给tableView
如：在AViewController中，我发起了数据请求，并拿到了原始数据，之后通过工具将其映射成了对应的Model，现在就用这些Model，来初始化ViewModel：
extension AViewController{
private func reloadAPI () {
let _ = AlamofireClient.default.send(requestAPI) { [weak self] (result) in
if let weak = self {
switch (result?.status)! {
case .success:
weak.basicModel = result?.respObject as! HLNormalModel
let lcVM = 理财ViewModel.wgp_creatViewModel(model: weak.basicModel!)
let spVM = 商品ViewModel.wgp_creatViewModel(model: weak.basicModel!)
let tzVM = 帖子ViewModel.wgp_creatViewModel(model: weak.basicModel!)
weak.dataArr.removeAllObjects()
weak.dataArr.add(lcVM)
weak.dataArr.add(spVM)
weak.dataArr.add(tzVM)
weak.table.reloadData()
break;
/*
这里可能并不是这个样子，可能会面临着后台一个数组返回，里面包含着不同的类型条目，这样的话就没办法了，只能根据某些条件进行if判断，然后创建不同的ViewModel了，或者也可以继续用protocol进行优化，不过我这里没搞得这么详细，部分模块中，这个地方还是会出现几个if的，不过我觉得没什么关系，大不了我让菊花再多转几圈呗，反正不会影响到什么。
*/
default:break;
}
}
}
}
}
最后一步，ViewController中的实现，或者说tableView的delotor如何实现
extension AViewController : UITableViewDelegate,UITableViewDataSource{
func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
return dataArr.count
}
func tableView(_ tableView: UITableView, heightForRowAt indexPath: IndexPath) -> CGFloat {
let viewModel = dataArr.object(at: indexPath.row) as! WGVMCellProtocol
return viewModel.wgp_getSpecificCellHeight()
}
func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
let viewModel = dataArr.object(at: indexPath.row) as! WGVMCellProtocol
let cell = viewModel.wgp_getSpecificCell(tableView: tableView) as! WGVMCellProtocol
cell.wgp_updateCellInfo(viewModel: dataArr.object(at: indexPath.row) as AnyObject)
return cell as! UITableViewCell
}
}
总结：
简单来讲其实就是建立了一种一对一的关系，类似 key:value,让复杂的列表逻辑变成这种形式。个人总结有以下几点好处：
1、页面可维护性增强，维护简单，增加或者减少某一类型 或者某些类型的Cell条目，只要针对新条目建立Cell和ViewModel并实现协议就可以了，或者通过注释掉创建某个类型ViewModel来控制某种条目不展示
2、列表滚动流畅度有所提升，毕竟不需要再动态的if-else来决定创建哪一个Cell了，这部分的计算时间被优化掉了，而菊花转动3圈和5圈用户是没有强烈感知的，只要不是耗时性操作，解析成ViewModel很快的，当然了，除非你谢了10以上的if-else才有可能出现可感知的体验提升
3、还可以通过给Protocol建立扩展，分担一部分业务，或者将Cell中的具体实现转移到协议的extension中，将代码业务粒度进一步变小
