好久没有更新简书了，可能大家都忘记了我（这么帅的一个程序猿）。
今天我为大家带来的是MVP的开发套路，帮助大家认识MVP，喜欢MVP。
MVP是什么？
MVP设计模式
view（客户），presenter（产品狗），model（程序猿）。
有一天，客户找到了产品狗说：“我要开发一个像微信一样的App”
然后，产品狗原封不动地转达了给程序猿，程序猿默默地说了一句：“傻X，有病”。
当然产品狗也不会这么傻，它当然要在客户面前夸他，于是在电话里头说：“我们的工作人员，对此表示有挑战性，但是他们很乐意。”
于是新需求就来了，最终苦逼的还是程序猿。
终于，程序猿受不了了，辞职了，但是又来了一批新的，需求还是需求，并不会因为人不同了，就推掉这单生意（重构项目）。
view（客户），contorler（产品狗），model（程序猿）
有一天，客户找到了产品狗和程序猿说：“我要开发一个像微信一样的App”
程序猿默默地说了一句：“傻X，有病”。
嗯，打起来了，项目没了。
通过这么深刻的故事，我们看到了MVP的优点
1.view和model相互不认识（解耦），并不会因为model不一样了，而影响了view，反过来也一样。那么model什么时候会变呢？例如，老子原来用的是Volley网络框架，但是我现在要换成OKhttp。没关系，我只需改动model即可。
2.model是面向接口文档编程的，view是面向设计图编程的，而presenter是负责协调的，这样就可以并行开发了。
3.测试，因为是view和model不认识（解耦），那么就可以单独地对model进行测试，验证它的准确性。做好了view，真机调试，又可以发朋友圈了。最后用presenter连起来，如果测试得好，Bug也会少很多。
4.做不好不用背锅，还可以多踩一脚（O(∩_∩)O~）。我做model的，数据给你了，你显示那么丑......这是一个后台跟App的故事。
5.presenter（产品狗），可以同时面对多个view（客户），做更多的事情（累死更多的程序猿）。
MVP的缺点
1.presenter负责逻辑，代码会多。（产品狗确实挺累的）
2.写得很累，明明view跟model可以直接相连，非要跟presenter联系，可能在传递时出现Bug。（明明程序猿可以跟客户面对面沟通，但是经过了产品狗，回来的需求就不一样了）
3.我还要想。（直接下个主题）
MVP开发攻略套路
model层
这是我开发的套路，希望你们喜欢。正常情况下，3天就能完成所有的接口文档对应的model。而在做model的时候，面对的是接口文档，没有比这个东西更接近需求了，因此，你做完之后会更加明白这个项目。
用Rxjava+Retrofit是什么体验
view层
简单但是暴力。我还有隆重地为大家推荐几款插件。
1.SelectorChapek for Android（自动生成Selector的XML文件），再也不要考虑那些乱七八糟的press，focus，normal
2.jimu Mirror（不需要写代码，就能在真机显示布局，包括列表），神器！加快了朕发朋友圈的速度。
3.butterknife（依赖注入库，自动注解布局中带@+id的控件），用完就更model的同学说，真慢！
4.Android studio自带的Get，Set生成器。
presenter层
Sept1
根据model的所需参数创建外部调用接口（presenter的方法接口）
Sept2
实现Sept1中的接口和model层提供的回调接口
Sept3
根据业务逻辑，调用view层提供的方法。
小结
由于model和view可以同时进行开发，提高了开发效率，减少了bug。
在外部调用方法中加上适当的注释，可以让我更好地沟通。
总结
MVP设计模式，是个很大的概念，我由于知识水平不够，很难跟大家讲得透彻。我只能按着我的理解来说明白，如果有哪些不对，请大家批评指正。
我前段时间做了一个ASP.NET mvc5的网站，虽然mvc5很清晰，但是在逐渐开发的过程中，model和view渐渐勾搭上了，到最后分不开了，我们也没办法。导致了项目重构的困难，最后的命运是重做。
我最近一段时间用MVP做了一个App，由于我对MVP的理解不到位，导致了代码很大部分的冗余，有一些没有必要提供外部调用的方法，我却硬要追求MVP模式的套路，结果导致了代码很乱，跟大家的忠告是，MVP是一个工程，不是一种硬性的规则，我们灵活一点。
我最近几天，做了一个看图的App，上篇文章介绍那个，我发现MVP模式上用上封装和继承，会让我们的代码更加的好看。而且复用率大大提高。
我是帅气小伙，在这里没有代码，有的只是我的想法，我的经验。希望大家喜欢！
