通俗易懂系列之Android中的MVP设计模式

说起MVP设计模式，做开发的可能都不会陌生，多少都会有点自己对它的理解。那么本篇博客就记录一下我对它的理解。

其实，从一开始我有点不理解为什么要有设计模式这种东西和为什么要去用它。如果说为什么要有设计模式，这个很好解决，设计模式可以让我们的软件更容易维护扩展，使代码之间的关系变得更加清晰。那么为什么要用它呢？本来一个Activity就可以解决的问题，竟然要额外写那么多接口和类，MVP三者之间这个持有那个，那个调用这个，天哪，怎么感觉比原来麻烦多了呢。我相信大部分初次接触MVP的人都有过这种想法。本次，我就详细说说MVP到底是啥，怎么理解它，用它能为我们的项目带来怎样的实际好处。

MVP是啥？
M—>Model，Model代表模型，可以存储、请求、操作数据。
V—>View，VIew代表视图，负责界面，用于展示数据、绘制UI元素、与用户进行交互，简单理解就是Activity、Fragment。

P—>Presenter，Presenter翻译过来是主持人、中间人的意思。不同于MVC设计模式，Model和View之间通过Presenter进行联系沟通。

先放一张MVP三者之间的关系图：

对MVP有了一个初步的了解后，可以进一步的去理解它了，设计模式的初衷就是为了降低代码的耦合，划分职责，使得业务和逻辑区分开来，隐藏多余数据，增强代码的灵活性。举个例子：
把Activity看做是一家餐厅，按照普通的开发方式来看，这家餐厅只有一个人在维持，自己点菜，自己响应自己的点菜需求（数据处理）,自己做菜再自己在端给自己（UI展示），要是真有这种餐厅，估计这个人也是个神经病，自己把本属于不同角色的事都干了。不过幸好有MVP设计模式，可以让他做个正常人。

还是把Activity看做为一家餐厅，不过这次不再是一个人了，而是有三个人，他们职责分工很明确，其中有个顾客叫View，有个服务员叫Presenter，有个厨师叫Model。可以想到，顾客(View)来点菜，告诉服务员(Presenter)要哪些菜，点完菜后服务员(Presenter)通知大厨(Model)来单了快去做菜，等大厨(Model)做好菜了，又通知服务员(Presenter)说菜做好了，于是服务员赶紧把大厨做好的菜端给顾客(View)。这就是一个典型的MVP模式流程，也更接近现实生活中的场景。这样能理解MVP模式是怎么回事了吧，它让餐厅的运营正常了起来，餐厅里的人各司其职，井然有序，放在代码里也是一样。

使用了MVP模式的逻辑是这样的

最后使用MVP模式可以为项目带来什么样的实际好处呢。先说说缺点吧，接口和类数量的暴涨是一个，理解成本是一个，比较费时间是一个。优点呢，用比较官方的话来说一是软件架构上具有明确的分工，各个模块的职责功能平衡分配，并且清晰明确。二是软件的可测试性提高，一般良好的软件架构都具备良好的可测试性。三是良好的易用性，维护成本低。不过确切的好处还是自己使用过后才明白，小项目就不推荐使用了，如果你想拿小项目练练手也是无可厚非的。
已上就是我对MVP模式的理解了，如果有什么不同的意见，希望大家可以在下面多多评论留言。