有的时候我们出于记录用户操作行为数据的需要，或者统一配置页面的目的，会从UIViewController里面派生一个自己的ViewController，来执行一些通用逻辑。
比如天猫客户端要求所有的ViewController都要继承自TMViewController。这个统一的父类里面针对一个ViewController的所有生命周期都做了一些设置，至于这里都有哪些设置对于本篇文章来说并不重要。在这里我想讨论的是，在设计View架构时，如果为了能够达到统一设置或执行统一逻辑的目的，使用派生的手段是有必要的吗？
我觉得没有必要，为什么没有必要？
1.使用派生比不使用派生更容易增加业务方的使用成本
2.不使用派生手段一样也能达到统一设置的目的
这两条原因是我认为没有必要使用派生手段的理由，如果两条理由你都心领神会，那么下面的就可以不用看了。如果你还有点疑惑，请看下面我来详细讲一下原因。
为什么使用了派生，业务方的使用成本会提升？
其实不光是业务方的使用成本，架构的维护成本也会上升。那么具体的成本都来自于哪里呢？
- 集成成本
这里讲的集成成本是这样的：如果业务方自己开了一个独立demo，快速完成了某个独立流程，现在他想把这个现有流程集合进去。那么问题就来了，他需要把所有独立的UIViewController改变成TMViewController。那为什么不是一开始就立刻使用TMViewController呢？因为要想引入TMViewController，就要引入整个天猫App所有的业务线，所有的基础库，因为这个父类里面涉及很多天猫环境才有的内容，所谓拔出萝卜带出泥，你要是想简单继承一下就能搞定的事情，搭环境就要搞半天，然后这个小Demo才能跑得起来。
对于业务层存在的所有父类来说，它们是很容易跟项目中的其他代码纠缠不清的，这使得业务方开发时遇到一个两难问题：要么把所有依赖全部搞定，然后基于App环境（比如天猫）下开发Demo，要么就是自己Demo写好之后，按照环境要求改代码。这里的两难问题都会带来成本，都会影响业务方的迭代进度。
我不确定各位所在公司是否会有这样的情况，但我可以在这里给大家举一个我在阿里的真实的例子：我最近在开发某滤镜Demo和相关页面流程，最终是要合并到天猫这个App里面去的。使用天猫环境进行开发的话，pod install完所有依赖差不多需要10分钟，然后打开workspace之后，差不多要再等待1分钟让xcode做好索引，然后才能正式开始工作。在这里要感谢一下则平，因为他在此基础上做了很多优化，使得这个1分钟已经比原来的时间短很多了。但如果天猫环境有更新，你就要再重复一次上面的流程，否则 就很有可能编译不过。
拜托，我只是想做个Demo而已，不想搞那么复杂。
- 上手接受成本
新来的业务工程师有的时候不见得都记得每一个ViewController都必须要派生自TMViewController而不是直接的UIViewController。新来的工程师他不能直接按照苹果原生的做法去做事情，他需要额外学习，比如说：所有的ViewController都必须继承自TMViewController。
- 架构的维护难度
尽可能少地使用继承能提高项目的可维护性。
那么如果不使用派生，我们应该使用什么手段？
我的建议是使用AOP。
在架构师实现具体的方案之前，必须要想清楚几个问题，然后才能决定采用哪种方案。是哪几个问题？
1.方案的效果，和最终要达到的目的是什么？
2.在自己的知识体系里面，是否具备实现这个方案的能力？
3.在业界已有的开源组件里面，是否有可以直接拿来用的轮子？
这三个问题按照顺序一一解答之后，具体方案就能出来了。
我们先看第一个问题：方案的效果，和最终要达到的目的是什么？
方案的效果应该是：
1.业务方可以不用通过继承的方法，然后框架能够做到对ViewController的统一配置。
2.业务方即使脱离框架环境，不需要修改任何代码也能够跑完代码。业务方的ViewController一旦丢入框架环境，不需要修改任何代码，框架就能够起到它应该起的作用。
- 其实就是要实现不通过业务代码上对框架的主动迎合，使得业务能够被框架感知
这样的功能。细化下来就是两个问题，框架要能够拦截到ViewController的生命周期，另一个问题就是，拦截的定义时机。 - 对于方法拦截，很容易想到Method Swizzling，那么我们可以写一个实例，在App启动的时候添加针对UIViewController的方法拦截，这是一种做法。还有另一种做法就是，使用NSObject的load函数，在应用启动时自动监听。使用后者的好处在于，这个模块只要被项目包含，就能够发挥作用，不需要在项目里面添加任何代码。
- 然后另外一个要考虑的事情就是，原有的TMViewController（所谓的父类）也是会提供额外方法方便子类使用的，Method Swizzling只支持针对现有方法的操作，拓展方法的话，嗯，当然是用Category啦。
- 我本人不赞成Category的过度使用，但鉴于Category是最典型的化继承为组合的手段，在这个场景下还是适合使用的。还有的就是，关于Method Swizzling
手段实现方法拦截，业界也已经有了现成的开源库：Aspects，我们可以直接拿来使用。 - 然后另外要提醒的是，这方案的目的是消除不必要的继承，虽然不限定于UIViewController，但它也是有适用范围的，在适用继承的地方，还是要老老实实使用继承。比如你有一个数据模型，是由基本模型派生出的一整套模型，那么这个时候还是老老实实使用继承。至于拿捏何时使用继承，相信各位架构师一定能够处理好。
/本文摘自 Casa Taloyum 的 iOS应用架构谈 开篇 /
网友评论