iOS 开发中，把一个比较大的控制器(ViewController)通过继承来把视图布局和事件分开，这样好不好？

[xiubin]

在项目中经常会碰见一个比较大点的 ViewController，子视图可能比较多，而且会处理子视图的各种代理事件，vc 中还要处理逻辑，网络、数据等。

所以，我对于这种情况的解决办法一般是：

1. 写一个基类，里面初始化各种子视图，并且约束布局。
2. 继承基类，数据、事件、逻辑等处理

这样看着是很舒服、很清晰了，但是否违反继承的初衷？

[cheng4741]

不到万不得已别用继承，楼上说过的 extension，viewmodel 都是很好的方案，还可以另外写一个类处理一些逻辑，然后组合到 vc 中，各种 delegate 可以交给这个类去处理

[holy_sin]

rx.fuckEverything, you need it

[blacklee]

用 category 是一个很不错的解决方案，一个实例（左边是.m 文件的代码行数）

[cdLI]

推荐一篇文章:https://www.raywenderlich.com/132662/mvc-in-ios-a-modern-approach, 用此类方式，我目前在公司做的项目 viewController 里的代码没有超过 300 行的

[blacklee]

另外感觉其实代码多并不是非常的让人难受。
还是应该在命名、组织上面多下点功夫。比如前些年有一个思潮是「我们不写注释，因为我们的代码已经足够易读易解」。不过这个层次还是很难达到，我练习了几年，仍然感觉功力不够。

[M80]

纯吐槽：category 的方案不就是等于把垃圾扫到沙发底下，然后装作房间已经整洁了么？
这么说的原因是，即使分割成了多个 category，各个实现上都有可能存在互相依赖。
如果简单的 ViewController 可以做的事情是：做 ViewModel，提取 UITableView/UICollectionView 的 Adapter，上下文无关的地方，提取 Util 等等一些朴实的方法。
而复杂后，可以推荐使用 http://clean-swift.com/ 里这种类 VIPER 的做法。
（其实说到底还是经验和练习不够

[sfz97308]

不倾向于用继承和 Category。可以根据实际情况，拆成 Child View Controller，或者加一层 ViewModel