iOS 开发中，把一个比较大的控制器(ViewController)通过继承来把视图布局和事件分开，这样好不好？
xiubin wxiubin 2017-07-05 16:49:16 +08:00 5388 次点击这是一个创建于 3024 天前的主题，其中的信息可能已经有所发展或是发生改变。
在项目中经常会碰见一个比较大点的 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 yemoluo 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 |
Select Language