初级阶段谁都能达到，真正的战争发生在反复完善阶段。
我在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个。这对一个刚开始健身的人，有非常大的鼓舞。
我会继续在“递减原则”上尝试。
最后推荐一下《比特新声》最新一期节目：
70. SP: 我们应该追求怎样的生活状态？
http://www.bitvoice.xyz/episode/70
