ViewModel，多个 ViewController 的动态更换

[cralison]

我在 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