Android 开发模式之MV模式

传统的Android开发模式是MV 模式，通常我们会编写一个BaseActivity，然后编写 一些基础的方法包括title，返回按钮，toast提示方法等等。然后在其他的子activity中实习对应的功能，以及各自的业务逻辑。这样做的好处是能完成快速开发，根据单个业务的逻辑操作包括View 交互都在同一个activity，能完成当个activity的快速开发。

通常使用这样的开发模式，我们都会在onCreate方法中初始化VIew并且绑定事件，然后请求数据，并且刷新View；

这样的开发模式 简单明了，但是缺点也不少。

1、首先在实际开发中有些复杂activity业务逻辑非常的繁多， 本人工作的项目中就曾经写过1000行+ activity，这类的activity后期维护 非常的费事费力，一旦功能稳定后有需求变更，修改起来非常麻烦， 尽管不断的加注释，往往都是牵一发动全身；

2、功能复用， 类型这样的编写模式一旦确定之后，功能复用也是非常麻烦，首先java是单父类接口的语言，遇到相同逻辑activity，我们通常第一想法就是写一个 基类然后子类实现不同功能，这样确实能解决一定麻烦，但如果遇到功能交叉比如 A、B、C三个Activity ，B既有A的功能又有C的功能，但是B不能即继承A又继承B，针对这样的功能有时候 需要抽出独立的工具类来 处理，但是项目过程中，因为开发人员或者项目工期的问题，有时候对于相同的我们做的 往往是复制黏贴，而不是 抽象提取，这样结果确实 能加快项目开发速度，但是后期需要调整的时候，动一个地方往往要改动很多地方。有事漏改的就是容易引发bug