一文形象生动地让你理解什么是MVP架构模式，看不懂你砍我

前言

本文将会以讲故事的形式加深理解。

在Android传统模式开发中，随着Activity的功能增多，其代码也在不断增加。那么我们很可能会发现，如果我们再要往Activity里边加一个功能，而恰好这个功能又要读数据库又要请求Http，
爆炸！加这么个功能要1000行代码（夸张），那么我们的Activity的代码就会变得十分臃肿，你没法快速地完成一个功能代码的修改。
因此，MVP架构模式正是解决这样一种情况的好方法

什么是MVP架构模式

在很多博客当中是这么解释MVP的，

• M：Model，实体层，用于实现具体的复杂的逻辑
• V：View，视图层，用于展示数据、交互等
• P：Presenter，逻辑控制层，用于持有Model和View的实例

然后就开始上一堆代码了。。。头疼

---

因此我写下这篇文章打算用一种形象生动的方法

首先你需要接受这么一个设定

• View：你
• Presenter：王大妈
• Model：工具人

这么设定只是为了帮助理解，不要问为什么是王大妈而不是张大妈，这只是一个虚的东西。

---

正式开始

故事：
你想要去买一瓶阔乐，以前的时候都是你自己一个人去买的，但是现在有一个王大妈出现了。
她说：“你把钱给我，可乐我帮你买，不多收费！”
你听了之后，这么划算的事情，那就这么定了。
于是你把钱给了王大妈，也把手机号码给了她。

但是我们都知道，天下没有免费的午餐，对于王大妈来说，这是个赚钱的机会。
王大妈知道一个低价买阔乐的渠道->工具人，他可以自己生产阔乐，因此价格便宜，她可以赚差价。
于是，王大妈找到了工具人，他们各自给了对方联系方式。

从此以后，你只要想喝阔乐，你就拨打王大妈的手机号跟她说。
而王大妈知道之后，她又打电话给工具人，向他要阔乐。
工具人听到之后，开始卖命地生产阔乐。

一段时间之后，阔乐搞出来了，工具人打电话通知王大妈，王大妈知道后又打电话通知你。

如此一来，阔乐就到手了。你也完全不知道阔乐是怎么来的，但确实到你手里了。

---

引入术语

这样以故事的形式来解释，我个人感觉会比较好理解。现在我们在故事的基础上将术语引入。

• 你：View
• 王大妈：Presenter
• 工具人：Model

从这种架构模式来看，View想要拿到数据显示，这个流程的逻辑将会变得十分清晰！

Presenter作为一个中间人，需要分两头联系View和Model。

而Model，只管把数据搞出来，再通知Presenter就好了，Presenter会做剩下的工作。

---

用代码举例

从上文可得知，王大妈和工具人都是十分具体的，但是如果另外一个张大爷也可以帮你完成代购，而且速度很快呢？

相信你一定也有了启发，这个时候 只要能代购到可乐，哪个中间人都行（只是效率问题）。

那有一天你不想喝阔乐了，想喝芬达了呢？

进一步处理

因此我们将这个Presenter（中间人）抽象，抽象成一个接口，只要能帮我们买到可乐，就能做这个中间人。
在中间人接口中，我们需要指定，这个中间人需要帮我们做些什么。（代购些啥）

同理，我们将Model（中间人）也抽象成一个接口，只要能干又苦又累的活都能做工具人。
在工具人接口中，我们需要指定，这个工具人要帮我们搞些什么东西。（生产些啥）

那你呢？你（View）也可以抽象成一个接口，我们需要指定，这个接口要些啥。（需要啥）

所以View需要啥→Presenter代购啥→Model生产啥，随后，
Model生产完成→Presenter代购完成→View心愿完成

这个流程都是十分清晰的，接下来直接上代码了

上代码，新建3个接口

新建3个包，分别为model，presenter和view



在presenter包中，添加MiddlePeople接口（中间人接口）

package cn.daccc.mvpdemo.presenter;/*** 中间人接口，只要能帮我们买到可乐，能通知我们就行*/
public interface MiddlePeople{//买可乐void buyCola();//购买成功后调用该方法void buySucceed();
}

在model包中，添加ToolPeople接口（工具人接口）

package cn.daccc.mvpdemo.model;/*** 工具人接口，只要能生产可乐就行*/
public interface ToolPeople{//生产可乐void produceCola();}

在view包中，添加Me这个接口，实现喝可乐的心愿（中间人买回来之后我们就可以喝了）

package cn.daccc.mvpdemo.view;/*** 实际上不一定是你想喝，你同学也想喝呢？就假装他也是“你”*/
public interface Me {//喝可乐void drinkCola();
}

---

我们添加了上面的3个接口，都是没有具体的实现的，也就是说，也就嘴上说说而已，没有实际行动
因此我们来建立真真实实的类，去完成上述行为

上代码，新建2个类

我们指定HanHan（憨憨）作为工具人，让他去帮我们生产可乐。

在model包中新建一个HanHan类

这里注意了，这个憨憨要符合工具人的特性，因此他要实现ToolPeople接口的所有方法，做工具人做的事。
因此，他要实现接口中的produceCola()方法

package cn.daccc.mvpdemo.model;
import android.util.Log;
/*** 工具人憨憨，他要符合工具人的特性才能帮我们做事，因此要实现Tool接口*/
public class HanHan implements ToolPeople {@Overridepublic void produceCola() {Log.d("ToolPeople","生产可乐好累啊！");}
}

你会发现，HanHan生产完了，怎么通知呢？所以，HanHan要知道中间人的联系方式，因此HanHan要在中间人联系他的时候保存好中间人的联系方式，然鹅HanHan并不知道中间人具体是谁，所以要用接口类型来保存中间人。

package cn.daccc.mvpdemo.model;
import android.util.Log;
import cn.daccc.mvpdemo.presenter.MiddlePeople;
/*** 工具人憨憨，他要符合工具人的特性才能帮我们做事，因此要实现Tool接口*/
public class HanHan implements ToolPeople {//保存中间人的联系方式private MiddlePeople middlePeople;public HanHan(MiddlePeople middlePeople){this.middlePeople = middlePeople;}@Overridepublic void produceCola() {Log.d("ToolPeople","生产可乐好累啊！");//HanHan生产好了，告诉中间人TA购买成功了middlePeople.buySucceed();}
}

在presenter包中新建WangDaMa类

现在已经有了一个具体的工具人了，但是我们还差个具体的中间人
因此我们指定WangDaMa（王大妈）为中间人，这王大妈既要有“我”的联系方式，也要找到一个符合要求的工具人并且保存工具人的联系方式，因此她找到了HanHan

package cn.daccc.mvpdemo.presenter;import android.util.Log;import cn.daccc.mvpdemo.model.ToolPeople;
import cn.daccc.mvpdemo.view.Me;/*** 中间人，指定王大妈是中间人，因此她要做所有中间人该做的事情*/
public class WangDaMa implements MiddlePeople {private Me me;private ToolPeople toolPeople;//保存“我”的联系方式，并指派HanHan为工具人，保存他的联系方式public WangDaMa(Me me){this.me=me;toolPeople = new HanHan(this);}@Overridepublic void buyCola() {Log.d("MiddlePeople","我来帮你买可乐");//让工具人去生产可乐toolPeople.produceCola();}@Overridepublic void buySucceed() {//买成了，通知“我”可以开始嚯阔乐啦me.drinkCola();}
}

在MainActivity中实现Me这个接口
我们找一个中间人做代购，因此我找到了王大妈。
我只要想喝可乐只需要点击一下按钮，就让中间人帮我买可乐，买完之后再告诉我就可以了

public class MainActivity extends AppCompatActivity implements Me{private MiddlePeople middlePeople = new WangDaMa(this);@Overrideprotected void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);setContentView(R.layout.activity_main);Button btn_drink = findViewById(R.id.btn_drink);btn_drink.setOnClickListener(new View.OnClickListener() {@Overridepublic void onClick(View v) {//点击按钮，就让中间人帮我们买可乐middlePeople.buyCola();}});}/*** 实现Me接口中的drinkCola方法，让喝可乐这件事情有一个更加具体的描述*/@Overridepublic void drinkCola() {Toast.makeText(this, "这阔乐真他*的好嚯！", Toast.LENGTH_SHORT).show();}
}

结果展示

诶，就很舒服

弊端

打住，舒服是暂时的，到底有没有必要为了喝个可乐去搞那么多乱七八糟的什么中间人工具人呢？

答案就是：请使用长远的眼光，来决定在具体Android开发项目中到底需不需要使用MVP架构模式

文章中这样的设计模式会增加很多的类的接口，这是一个弊端，当然可以优化！
由于篇幅原因，我会把优化后的MVP架构个人理解放到下一篇博文中，敬请期待。

总结

从上边的故事和例子来看，是不是都理解了呢？如果还不理解，你来砍我（顺着网线来）。
哈哈，开个玩笑，我们来总结一下

• ToolPeople：实际上是Model，它做很多又苦又累的工作，因此把业务代码放在这里
• MiddlePeopl：实际上是Presenter，它做一个中间人的角色，可以执行少量的业务代码，比如简单判断这件事情能不能干的成
• Me:实际上是View，喝可乐这件事情最终体现在View中，但是它无需知道可乐是怎么来的，它只需要委派中间人去实现就可以了

最终总结

这里的什么憨憨，王大妈，“我”。都是为了帮助理解而已，相信认真看完文章的人，应该都理解了，因此这些类的名称，这些接口的名称，都应该按照规范来命名

编程很少是一个人的工作，所以学习如何架构代码是进阶的必经之路。本文分享了我对MVP架构的一些浅见，希望能够帮助大家理解。

如果文章有误，恳请指出，十分感谢！

机会，总是留给有准备的人。

共勉