扫码关注官方订阅号
看了objc.io的文章很疑惑
光阴似箭催人老,日月如移越少年。
可以的,这样把UITableView完全抽离出去,作为一个 Director 统一控制。objc 的文章只是提供个思路,毕竟 delegate 的代码其实不多,datasource 往往才是大头
我觉得是一定要。
因为numberOfRow、cellForRow这两个方法是在dataSource里,但是heightForRow却是在delegate里。我个人认为它们完全不应该分开。
numberOfRow
cellForRow
dataSource
heightForRow
delegate
datasource尽量拆出去: 它的任务可能是 1)获取初级数据 2)在1)的基础上如果需要进一步的转化为UI数据,这里做一层转化成UI可以直接使用数据,比如:lableTextString(s), XXimage(s), xxCellItem(s)。。。 拆出去的好处是为了让viewController职责更清晰明了,更模块化,代价就是加了一个属性(中间层)。如果你一个controller有多个tableview或者collectionview又或者你的数据比较麻烦。那你最好拆出去!
lableTextString(s)
XXimage(s)
xxCellItem(s)
delegate看你了具体需求了。拆出去可能会使得原本一个页面间的数据传递会显得比较蛋疼。。所以这里你要权衡~
anyway,任何模式都是看需求的。。。不是死的,如果你一个视图控制器压根没啥复杂的功能,你完全可以写在一起。任何模式都是有实际场景的,脱离了场景一切都没有意义!
微信扫码关注PHP中文网服务号
QQ扫码加入技术交流群
扫描下载App
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
PHP学习
技术支持
返回顶部
可以的,这样把UITableView完全抽离出去,作为一个 Director 统一控制。objc 的文章只是提供个思路,毕竟 delegate 的代码其实不多,datasource 往往才是大头
我觉得是一定要。
因为
numberOfRow
、cellForRow
这两个方法是在dataSource
里,但是heightForRow
却是在delegate
里。我个人认为它们完全不应该分开。datasource尽量拆出去:
它的任务可能是
1)获取初级数据
2)在1)的基础上如果需要进一步的转化为UI数据,这里做一层转化成UI可以直接使用数据,比如:
lableTextString(s)
,XXimage(s)
,xxCellItem(s)
。。。拆出去的好处是为了让viewController职责更清晰明了,更模块化,代价就是加了一个属性(中间层)。如果你一个controller有多个tableview或者collectionview又或者你的数据比较麻烦。那你最好拆出去!
delegate看你了具体需求了。拆出去可能会使得原本一个页面间的数据传递会显得比较蛋疼。。所以这里你要权衡~
anyway,任何模式都是看需求的。。。不是死的,如果你一个视图控制器压根没啥复杂的功能,你完全可以写在一起。任何模式都是有实际场景的,脱离了场景一切都没有意义!