前言
近期经常在群里看到大神们在讨论MVC MVP之类的东西，之前对MVC倒有一些了解，也还有一些印象。因此也激起了对MVP探讨的兴趣。这几天都在简书上翻阅相关文章，也动手写了些demo。目前也还是云里雾里的，也许真要在项目中运用起来了，才能真正领会吧。
初衷
看了很多文章对于为何需要MVP模式都有相应的介绍，大体的思想都是为了更好体现“低耦合、高内聚”的设计思想，也就是为了提高代码的可读性和可维护性。关于这点，我有比较大的感触，前段时间，接手一个同事的代码，发现其中一个activity的代码将近2000行，方法体也是多得数不过来，其中涵盖的功能自然臃肿，估计让他来解释，也解释不清了。其实想想，我们很多时候也是这样，项目一启动，完工工期就摆在那里，不得不去正式，很多功能都是想着先实现，后期再优化。但项目能准时上线已经是庆幸了，哪还有优化、重构的时间。因此就会导致上述一个类中，代码臃肿，功能错综复杂，调理不清晰、维护极其困难等不良情况的出现。
VIEW
基于上述初衷中所描述的问题，大家都会很自然地想到，view（在android中体现为activity）就应该只履行其展示视图的功能，简单明了。MVP模式就是这么做的：
View：绘制UI元素，展示视图。
这也是我们日常使用的app中展示其形态的最直接方式，如显示一张图片，一段文字，一个按钮等。就如同透过一个人的外观来获取自身对他的印象。
MODEL
研发应用，必然离不开数据这个概念，不管是静态的图片，还是从后台获取的某个动态数值，都是数据的存在形式。在MVP模式中，将对数据的操作独立成为一个模块，即Model：
Model:负责数据（本地数据、平台数据）操作（增、删、改、查）
PRESENTER
从上面两个角度来看，数据是数据，界面是界面。但我们实际使用中，数据要依赖于界面才得以展示，用户在界面上所做的操作，也会涉及到数据的变化。M和V之间有着必然的联系，在MVP模式中，将该部分操作写在了P里面：
Presenter:处理用户交互
