如果你写死类型，就是程序在玩你。

如果你多用协议对象，就是你在玩程序。

稍为正规一点的产品开发流程的第一步，应该是产品经理给出原型图，类似于下面这样子(图片引用自网络，如有侵权，请第一时间告知，我会尽快撤掉，谢谢)

原型图

然后，第二步是由设计师给出效果图，类似于下面这样子：(图片引用自网络，如有侵权，请第一时间告知，我会尽快撤掉，谢谢)

效果图

大家可以看到，这两者中间的差异非常大，如果等效果图出来后才开始开发，将会浪费前面的太多时间。但是，如果在原型图出来后，就直接开始开发，一不小心，后期就会是没完没了的反复修改。

VIPER

(图片引用自网络，如有侵权，请第一时间告知，我会尽快撤掉，谢谢)

VIPER，通过把APP架构划分为线框、视图、展示、交互、实体、数据六个层次，使得开发工作可以在最早的时候就参与进来，并且完全可以开发出后面无须改变的整体架构代码。

使用VIPER架构，可以在AppDelegate里通过唯一的一个实例对象管理整个APP的依赖，并且非常直观地管理整个APP的实例对象关系。

我在实际使用过程中，因为不希望依赖及实例管理类过于庞大以及提高代码复用率，把依赖管理和实例管理的代码分散到各个线框层的类里面。每一个纵向的业务所包含的类的依赖和实例管理，都交由各自的业务线框来完成。

通过视图、事件、交互三组协议的协议对象，使得视图显示、事件处理、交互数据这三块的类可以得到彻底分离。未来面对APP功能修改或增加时，将会变得非常容易，代码变化被约束到了最小的范围。

随着对VIPER架构的日渐熟悉，我越来越感受到协议对象的好处。通过协议对象的大量使用，每个类都可以也应该做成功能相对单一，专职专责，代码复用成本迅速降低。

通过越来越多的“单一职责”类的积累，将会极大地提高开发工作的效率和质量。

欢迎大家跟我讨论VIPER架构的相关问题，我会将我所知道的所有VIPER方面的知识和经验分享给大家：）

后记(下面有聊家常为主，没时间没兴趣的朋友请直接忽略)：

我一直犹豫要不要写后记，因为一直以来，我的文字都会写很多我自己的生活经历和思考。这一块有相当一部分朋友并不喜欢，认为我只需要把技术分享出来就可以了，没有人对我的生活和思考有任何兴趣。

后来，我觉得相对于技术的分享，我的生活和思考，才是日后对我真正有意义的东西。但为了不影响只关心技术的朋友，所以才有上面一开始的“后记声明”。

因为最近投简历上的一些经历，促使我打算每天写技术博客，最简单的目的自然是为了记录和展示自己的所学所知。更深一层的目的是希望自己能保持一个表达的习惯，把脑袋里的所有信息都清出来，这样才方便我去思考新的信息。当然，以我的经验，只要我坚持表达，就可以得到源源不断的帮助和机会。

为了不让自己在表达上有过多的压力，我给自己定了一个非常低的指标：100字。今天当然已经超了，光技术这一块就有600多字。希望自己可以一直写下去。从记录自己的开发工作和技术阅读开始，一直写下去。

今天儿子被非常脏的公共浴室给吓哭了，我得快点多赚点钱给老婆儿子换更好的房子住才行。

今天跟粉丝群里的朋友聊了一下，怎样才能更好的积累技术？目前我自己的结论还是：快速做一个简单的框架，然后每天每事每处反复去完善它。希望在技术积累上可以不断地提速：）