VC模式

本文讨论一种典型的“错误”设计：VC模式。

VC模式，由View+Controller组成。具体到iOS开发中，由View+ViewController组成。

和传统VC模式把V和C写在一起不同，那样所有业务，逻辑，数据，界面都在一个超级大类里，相当不好维护。具体说来，可以把ViewController看成是爹，这个爹只负责“生”View，以及协调他多个儿子之间交流。这个爹不管孩子长成啥样，长大了能干什么。

View是儿子，他既不管爹的私生活，也不管他兄弟的私生活，他只喂自己袋盐。全权负责自己的一切。如果有用到兄弟的地方，就找爹。

如此，一旦遇到问题，这个问题是哪个儿子负责的就找哪个儿子。逻辑简单，定位快速，除非——这个儿子管的事特别多！如果有一个特别复杂的View，按照以上逻辑它负责实现自身的所有业务，仍然会造成一个超级大View，同样不好维护。此时他需要再生一些儿子。

孙子View是儿子View上的subView。它们把儿子View拆分成了多个业务简单，逻辑简单地小View。此时每个小View逻辑简单，定位快速。此时儿子View不再是一个超级大View，他需要做的只是“生”孙子，并协调多个孙子之间的交流，作用类似ViewController对View。

至此，VC模式完成。

优点是：1、入门低。就像玩积木，把不同的模块凑起来就搞定；2、易维护。哪出问题直接定位那，不会存在过多的引用，嵌套。比如传统模式，还要去model定位数据，还要去Controller定位逻辑；3、易扩展。由于View本身实现了自身所有功能，复用及其方便。直接整块使用就ok。

缺点是：当业务不变，需要更换或新增View呈现的时候，由于View和数据耦合，导致不灵活。

补充：

1、View实现自己所有业务不是指取数据的业务都完全自己写，在每个View都实现一遍。oop的基本理念还是相同的。还是会有封装的类去做对应的事，只是减少了嵌套。