安卓的MVP模式是什么？与普通的写事件处理函数有什么区别？
MVP是不是就是多了个presenter类来持有安卓的view对象，处理数据与刷新view？
与普通的写事件处理函数区别是不是就是把在事件处理函数里的代码，挪到了presenter类里面？
但是如果只是这种区别的话，好像也没什么特别的，我们写代码不都是这么抽象的吗？把业务逻辑抽象到一起，为什么要单独拎出MVP这个概念？
收藏
收藏
收藏
Copyright 2014-2024 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
2
857
![ThinkPHP5实战之[教学管理系统]](https://img.php.cn/upload/course/000/000/068/6253d87459486427.png)
个人看来优点有以下几个：
1、逻辑清晰，界面的归View，数据处理的归Presenter，不至于出现Activity和Fragment大爆炸，读起代码来十分要命，后续的维护和升级也会带来很大的方便。我在看别人写的代码的时候，最怕分层不清楚，十分吃力。
2、测试方便，Presenter可以单独抽出来测试，不用和View绑定在一起测试，出错了也好排查。
你这么说是没错啦，专门用presenter来处理view。
我认为的好处：
1.presenter正常接收的是一个view的接口，这个应用DIP（依赖倒置原则），就是让我们尽量依赖抽象，这样任意一个view，只要实现了这些接口，那么他们都可以共用这些处理逻辑。
2.应用了SRP(单一职责原则)，可以让数据处理逻辑层与view分离，解耦
其实只是我们在开发中的随意性有点高，按照OCP原则，对扩展开发，对修改封闭，一个Activity可能会有 v1 v2 v3版本，那么这时候你去修改代码的时候，可能就是把以前的代码推到重来，或者在以前的代码基础上修改，这是比较危险的行为，而且也是一个没效率的行为，用了MVP，那么当你出现了v2、v3版本的时候，可能增加了几个控件，或者减少了几个控件，此时你如果是直接去修改之前的代码，那么mvp框架确实没有鸟用，但是你以扩展的方式来进行开发，就不一样了，多了几个控件，那么写个新interface继承原来view的interface，然后再来一个新的presenter继承旧的，在这里面进行新逻辑的编写，维护上面和方便，测试也只需要测试新的代码就行了，程序的稳定性可以增强。
所以如果遵照mvp模式来写，不知不觉中的你代码的可维护性就变强了。