MVP模式

最新接手的项目写回了MVC模式，然后就是功能的完善和bug的修改，然后觉得还是自己还是得把mvp模式安排一下。

MVC模式
分别是Model（数据）、View（视图）、control（控制逻辑）
Model层这个就是咱们所说的bean实体类也就是保存的对象数据，想要拿数据的时候就获取一个对象然后点点点属性就得到了
View层这个单词代表的很好因为咱们只要可以看到的交互页面，全部都是View这个类的子类，所以View就是UI界面给用户观看和接受用户的输入数据
Control层也就是像他的名字一样属于逻辑的控制器，他和View层就是一起堆在Activity里面。

1.png

写代码的宗旨就是高内聚低耦合，但是在Activity中会随着功能的复杂逻辑代码越来越臃肿（没错，还有像我这种adapter懒得抽出来也直接写在activity里面的）。所以接下来就介绍一下MVP模式的舒服之处。

MVP模式
分别是Model（数据）、View（视图）、Presenter（主持者）
Model层没有变
View层也没有变他还是在activity里面但是他不会再与model层进行直接交互，数据不像以前一样直接在acitivity里面进行交易QAQ
Presenter层这位我还是说说我使用的情况吧，我只是对我自己知道的进行总结，其他比较6的模式我还不清楚，因为听说还有很多的变形

2.png

这个模式的使用我都是在网络框架中进行使用别的部分为了activity代码简洁都是把adapter一类的抽取出来，一共需要两个类和一个主持者接口（就是一个普通接口，为了区分方便才交这个名字的）两个类分别是avitivity和presenter，activity实现主持者接口，让presenter中new一个主持者接口对象，当Presenter的方法被调用的时候，在Presenter的方法中处理网络调用，成功之后将网络接口返回的信息传递到主持者接口的方法中，因为acticity实现了主持者接口就能在重写的方法中获得Presenter调用网络接口返回的数据。

这样一来本来在model层中的逻辑处理代码，变成了从Presenter层接口返回的值，MVP与MVC的不同点是M层与V层不可以直接进行交互，而是通过P层进行数据和逻辑的传递，当后期项目变得庞大的时候，可以很快的清理项目和找到需要改动的地方，高内聚，低耦合的可也通过接口更加方便的进行但愿测试。
就先写到这了以后有的进行补充（捂脸。。。）