ViewModel，多个 ViewController 的动态更换

我在 ViewModel 上用得比较浅，都只是用来做数据调整。

有朋友希望我能在这方面多讲一点。问题是我懂的实在有限。

ViewModel ，在我这边，无非就是把传入的 Model 对象的属性值转换为适合 View 显示的值。 ViewModel 的意义其实跟所有独立出来的类是一样的：复用。

假设，你在 10 个地方用到同一个类型的 Cell ，那么最原始的做法是在这 10 个地方都写一遍数据调整的代码。而有 ViewModel ，你就可以直接把 ViewModel 对象给到 Cell 的定义方法，就可以完成 Cell 的数据展示处理，方便很多。

同样的道理，可以用到很多代码设计的地方。比如接下来我要说的。

有这样一个需求。屏幕上有多个 ViewController 的 View 需要滑动显示。而 ViewController 的具体类型，需要通过拉取后台的数据来动态更换。 ViewController 里相应的 API 调用、参数列表、数据存储等，都得一一对应着改变。

这里有几种设计。

其中最直观的设计是创建与后台数据一一对应的 ViewController 类，返回哪个数据就调哪个 ViewController 类，请求、参数、存储分别放到对应的 ViewController 类中。

但这种设计将会带来类爆炸。比如，有 5 大分类，每一个大分类底下都有 5 个子分类。也就是说，最少也得 25 类才能满足一个页面的显示。

极端点的设计， 25 种不同的数据，通过 1 个 ViewController 的处理。那 25 个不同的请求、参数、存储怎么办？这个时候，需要一套把类中变化部分派发出去的机制。

协议对象就是用来解决这种问题。

我们会创建 25 个符合同一协议的类，却只用 1 个 ViewController 。

至此，好像采用协议对象并没有比原来更，原来只需要 25 个 ViewController 类，而现在不但需要 25 个协议类，还需要 1 个 ViewController 类。在类的数目上，反而比原来还要多 1 个。但是，考虑到 ViewController 里的代码极难复用，通过协议对象处理变化就有了优势。

协议对象的变化处理机制，即更有助于代码模块化。随着项目需求迭代成长，优势将会越来越明显。

还有一个问题想跟大家探讨。

项目初期要不要为了快速跑通业务逻辑而容忍代码大量地重复(显然是 command C/command V 产生的)？

我自己的想法是，不应该在项目初期纵容自己去写大量的烂代码。因为之所以出现重写，正是因为前期为赶进度把代码写得太烂，使得后面重构和维护都极其困难。

如果我们为了快速跑通业务逻辑而容忍大量烂代码存在，那么势必在业务逻辑跑通后，又要花大量的时间人力去重构代码。

后记(下面以聊家常为主，没时间没兴趣的朋友请直接忽略)：
今天，仰卧起坐只做了 153 个，比昨天少了一半。我在尝试新的做事原则：递减原则。昨天，我用的是“等量多组原则”，每一组只做 50 个， 6 组做下来就有 300 个。今天第一组就实现突破， 75 个。问题是，第二组时，我发现做不动了，只做了 3 个。第三组 63 个，看似有点回归正常。但第四组却只做了 12 个。总共才做了 153 个。

如果说健身，有身体的极限和限制。其实做其它事情也一样，总会有各种影响和限制，如果我们在第一回合就过度发力，有可能到了第二回就什么都做不了。这样，在总量上反而很吃亏，还不如用“等量多组”。

这次“递减原则”的尝试，也不是全无收获，起码知道自己仰卧起坐居然可以做到 75 个。这对一个刚开始健身的人，有非常大的鼓舞。

我会继续在“递减原则”上尝试。

最后推荐一下《比特新声》最新一期节目：

1. SP: 我们应该追求怎样的生活状态？

http://www.bitvoice.xyz/episode/70