在项目中经常会碰见一个比较大点的 ViewController,子视图可能比较多,而且会处理子视图的各种代理事件,vc 中还要处理逻辑,网络、数据等。
所以,我对于这种情况的解决办法一般是:
这样看着是很舒服、很清晰了,但是否违反继承的初衷?
1
googlebot 2017-07-05 17:25:01 +08:00 via Android
apple 的思路是搞 delegate,不需要继承,你可以定义自己的 delegate,
cocoa 的系统架构比 ms 水平高多了,windows 都是 api,com,cocoa 是各种 delegate, |
2
zetasq 2017-07-05 17:37:10 +08:00
如果你这个 UI 其他地方也要用到,但是每处的数据和逻辑不一样,那么写一个基类比较方便(比如 UITableViewController) 。如果只有一个地方用到,基类感觉没啥用(初始化代码太多的话,可以尝试在每个 subview 的 initializer 里分担逻辑)。不过一般业务代码 viewcontroller 的文件都会比较大,做好 mark 就好了
|
3
zengyuxi 2017-07-05 17:42:01 +08:00
MVVM (非 RAC )
如果会 RAC 的话,更好! |
4
HelveticaNeue 2017-07-05 18:05:16 +08:00
个人不喜欢这种继承。
分层、分模块的本质是为了高效地复用代码。如果不存在复用代码的需求,为什么要拆开布局和业务?我觉得这种分层反而增加了复杂度。用 MARK 分好段落就可以了。 |
5
allenzyq1314 2017-07-05 18:11:31 +08:00
反正无论什么都有 1 2 个 baseviewcontroller。 就怕以后加业务逻辑会写太多多余代码。。
|
6
GTim 2017-07-05 18:13:50 +08:00
swift 的话 extension 值得拥有
|
7
ma125125t 2017-07-05 18:16:47 +08:00
子视图当做 viewcontroller 来做,作为主视图的 child viewcontroller,这样就不违背 MVC,也能精简代码了呀。
|
8
xi_lin 2017-07-05 18:20:30 +08:00
你的场景要的是 subViewController 吧
其实 category 也行 |
9
a412739861 2017-07-05 18:21:57 +08:00
和 ls 相似,感觉应该用 child ViewController,child ViewController 也能复用。
|
10
LINAICAI 2017-07-05 18:31:41 +08:00
永远不要让视图去处理网络数据,你要做的是拿到数据后把数据扔给视图然后刷新视图
|
11
GaoMjun 2017-07-05 18:55:21 +08:00 via Android
viewcontroller 几千行正常
|
12
Durandcol 2017-07-05 19:01:24 +08:00
1.在需要复用的前提下 再对之前的代码做分层
2.不要执拗于 MVC MVVM 本质上只是放代码的地方, 只是方便程序员维护与理解 搞了一层抽象的东西. 3.继承不要搞太多层. |
13
xiubin OP @googlebot #1 继承和 delegate 没直接关系吧?继承是为了复用和扩展,delegate 是事件 /数据回调和分发才用的吧?
@zetasq #2 我也是这么想的,可能最近重构公司项目看多了 2、3k 行的控制器烦了,想把所有的控制器代码减到 3、4 百行(也只是想想~)。我说的这个控制器的子视图其实有 self-manager 的概念,该控制器的直接子视图并不负责渲染和显示,而是又管理了一大堆的视图,说是 View,其实承载的是 Controller 的功能。 @ma125125t #7 @xi_lin #8 @a412739861 #9 是的,我上面的回复也有提到,这个控制器的直接子视图是 Controller 的作用,其实用 child ViewControlle 是最好的 |
14
34D 2017-07-05 22:23:50 +08:00
category
|
15
jesse_luo 2017-07-06 00:54:15 +08:00
1. 减少继承,增加组合
2. 没人说 view delegate 一定要用 VC 处理吧 3. View 不要自己处理业务逻辑 |
16
googlebot 2017-07-06 07:08:15 +08:00 via iPad
继承是非常差的架构,代码非常难维护,代码分离太差,
出了问题你都不知道在第几层出的问题, |
18
free9fw 2017-07-06 09:15:56 +08:00
swift extension+RxSwift
|
19
JasperYanky 2017-07-06 09:25:13 +08:00
1.可以试试 ViewModel
2.可以试试 Category |
21
cheng4741 2017-07-06 09:50:06 +08:00
不到万不得已别用继承,楼上说过的 extension,viewmodel 都是很好的方案,还可以另外写一个类处理一些逻辑,然后组合到 vc 中,各种 delegate 可以交给这个类去处理
|
22
holy_sin 2017-07-06 09:52:41 +08:00
rx.fuckEverything, you need it
|
23
blacklee 2017-07-06 09:56:02 +08:00
用 category 是一个很不错的解决方案,一个实例(左边是.m 文件的代码行数)
|
24
cdLI 2017-07-06 09:59:18 +08:00 1
推荐一篇文章:https://www.raywenderlich.com/132662/mvc-in-ios-a-modern-approach, 用此类方式,我目前在公司做的项目 viewController 里的代码没有超过 300 行的
|
25
blacklee 2017-07-06 10:04:29 +08:00 1
另外感觉其实代码多并不是非常的让人难受。
还是应该在命名、组织上面多下点功夫。比如前些年有一个思潮是「我们不写注释,因为我们的代码已经足够易读易解」。不过这个层次还是很难达到,我练习了几年,仍然感觉功力不够。 |
26
M80 2017-07-06 10:13:27 +08:00
纯吐槽:category 的方案不就是等于把垃圾扫到沙发底下,然后装作房间已经整洁了么?
这么说的原因是,即使分割成了多个 category,各个实现上都有可能存在互相依赖。 如果简单的 ViewController 可以做的事情是:做 ViewModel,提取 UITableView/UICollectionView 的 Adapter,上下文无关的地方,提取 Util 等等一些朴实的方法。 而复杂后,可以推荐使用 http://clean-swift.com/ 里这种类 VIPER 的做法。 (其实说到底还是经验和练习不够 |
27
sfz97308 2017-07-06 16:26:09 +08:00
不倾向于用继承和 Category。可以根据实际情况,拆成 Child View Controller,或者加一层 ViewModel
|