本文总结的是@李洁信分享的面向协议编程，首先感谢@李洁信非常睿智的演讲，用通俗的语言诠释了swift面向协议变成的本质。
首先一个例子带我们见识什么事协议，如何使用协议去编程。
然后，让我们大致了解了一下：swift 中的协议
可以看到，swift这门语言说是一门面向协议编程的语言一点都不为过，protocols:classes = 11：1,swift大大弱化了oop，所以，既然走上了swift这条不归路，那就要拿上他最最厉害的武器来武装自己。
后面，@李洁信用直观的代码像我们介绍了传统的oop给我们带来的一些困扰，比如
god class
老外形容一些事物有时候真的非常的形象，一个无所不能的类，想想一下，所有的功能都集中在一个类中，大家只要继承这个类，那么就获得了这个类的能力。
那么，这样做真的好吗？@李洁信的回答是并不好！
当然我也有自己的看法：有好处，也有坏处。
好处：需求变了，统一替换样式，我们只用动上帝类
坏处：正如@李洁信说的那样，上帝类达到1000行不是不可能，超过500行其实就是比较难以维护了，其次，BaseTableViewController怎么办，在复制一份上帝类过去？还有一点，开放封闭原则哪里去了呢？
mvp
那么，就上面的问题@李洁信拿出了mvp做重构，最后得出的结论显然就是，mvp效果也并不好
个人认为也没有什么不好，至少简化了view，至少也在之前的继承的基础上更加进了异步，使用了组合
@李洁信给出的原因：有点笨重,实现代码多，使用时要自己管理实例的创建和释放，而且还多了层次结构，我觉得也说的过去，赞同👍
protocol version
其实MVP不是不好，只是还有更加好的方式，
聪明的小伙伴已经看出来了，这种方式相比mvp来说
- 代码没有增多,却更复用
- 面向向协议(接 ), 不是实现,充分解耦
- 静态类型检查帮助在编译时发现问题
- 写代码像搭积 ,先设计接 ,再一一实现
- 依赖少,更容易调试
mvvm
至于后面还讲了一个mvvm，我对那个其实并不是很感冒，model的数据无法直接用到view上，然后在中间加上一层viewmodel，viewmodel更加像一个配置表，配置记录着model和view之间控件的对应关系，实际上增加一个控件，要改的地方也不是说只改一处，也并不是很简单吧。所以，我并不推崇，也不排斥。
总结
swift中，我们在做设计的时候，应该考虑的是，一个功能模块应该划分为那几个协议去实现，而不是把这个功能封装在摸个类中，提供一个对外的方法。
