Android MVP升级路系列文章目录：
- （一）乞丐版的自我救赎
- （一）轻项目标配之时尚版
01 序
第一、二章中有些类的命名存在笔误，目前发现的已纠正。
如果你有把前两篇文章认真的看完，那么你已经基本掌握了MVP架构核心思想，可以在实际开发项目中使用它了。
有不少问我要源码demo的朋友，demo确实有，前面文章之所以没留下源码是因为我更希望你能够亲手写出来一套属于自己的东西，在这过程中你可以反复斟酌各层之间的逻辑，包结构以及如何设计父类的通用方法。建议还没手写过的朋友停下来去写一套自己的MVP。
鉴于前面文章已经算是MVP的入门，本文主要聊一些实际使用中架构项目时的思考。
02 Token的有效性
在第二章中我们利用了类似策略模式的方法对Model层实现了统一管理，利用Token标识不同的model，可是这样会存在一些隐患。
例如当我们给一个已经登记在Token中的Model类改了名字，必须同时去Token中更新手动一下对应的字符串。抛开增加维护成本不说，一旦有一个类我们忘记手动更新，那么它就不能用了。
显然，意识到这个问题后此方法必须立刻优化。
放弃Token，直接对类反射
上一章说道，token其实就是描述某个model类“包名+类名”的字符串，有了它我们就可以得到这个类对应的class对象，从而实例化出对象：
model = (BaseModel)Class.forName(token).newInstance(); // 使用token实例化对象
既然token有限制，我们就直接跳过token解析这一步，直接传递class对象：
public class DataModel {
public static BaseModel request(Class clazz) {
// 声明一个空的BaseModel
BaseModel model = null;
// 判断class对象是不是BaseModel的实例
if (clazz instanceof BaseModel) {
try {
//利用反射机制获得对应Model对象的引用
model = (BaseModel) clazz.newInstance();
} catch (ClassNotFoundException e) {
e.printStackTrace();
} catch (InstantiationException e) {
e.printStackTrace();
} catch (IllegalAccessException e) {
e.printStackTrace();
}
}
return model;
}
}
请求数据时直接传递model的class对象即可：
DataModel
// 设置Model
.request(UserDataModel.class)
// 添加请求参数，没有则不添加
.params(userId)
// 注册监听回调
.execute(new UserCallback());
到此我们已经解决了token方法中更新类名需要手动同步的问题，但是还并不完美。假如一个项目中有10处位置调用了同一个model，当这个model类名有变化时这10处均发生了改变，虽然IDE会自动帮我们修改其他地方，但是终究还是发生了多余的变化。
理想状态下，我们希望无论model被多少处调用，它自身的改变并不会影响其他地方，那要怎么做呢？方法有很多，比如采用Token方法映射等等，大家一起想想呀欢迎留言~
03 通用的callback
在数据请求中我们需要在callback的各个回调中分别取处理对应的请求结果，但是你只要写多了就会发现，除了请求成功的回调方法，其他的像请求失败，请求出错这些方法我们做的事几乎是一样的。
那既然这样，我们是不是可以构建一个通用的BaseCallback去处理请求的异常情况呢？
04 链接view
在第一章我们封装了base层后，虽然大大的减少冗余代码，但是在每个activity我们都要去手动操作presenter与view的链接与断开操作，这显然不是很美好的。
优化的办法也很简单，我们都知道每个activity都继承于BaseActivity，每个presenter都继承于BasePresenter，所以，我们只需要在BaseActivity中实现BasePresenter链接view的操作即可。
在BaseActivity中：
public abstract class BaseActivity extends Activity implements BaseView {
/**
* 获取Presenter实例，子类实现
*/
public abstract BasePresenter getPresenter();
/**
* 初始化Presenter的实例，子类实现
*/
public abstract void initPresenter();
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
initPresenter();
if (getPresenter() != null){
getPresenter().attachView();
}
}
@Override
protected void onDestroy() {
super.onDestroy();
if (getPresenter() != null){
getPresenter().detachView();
}
}
// 下面代码省略...
}
在具体的Activity中使用：
public class MainActivity extends BaseActivity implements MvpView {
// 继承于BasePresenter
MvpPresenter presenter;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
}
@Override
protected BasePresenter getPresenter() {
return presenter;
}
@Override
protected void initPresenter() {
presenter = new MvpPresenter();
}
// 下面代码省略...
}
在上面的例子中，我为了更直观的展示效果设计了两个抽象方法，分别是初始化和获取presenter，当然其实完全可以只有一个获取presenter方法就行，看自己喜好即可。
05 思想
能读到这里的朋友相信都是真爱没错了，不知道朋友你有没有发现无论是前两章讲的那么详细但是没给源码，还是这章的点到为止，我都是在强调思想要远比代码重要。
其实MVP本身的代码，格式什么的并是不那么重要，重要的它的核心思想，以一种什么样的方式工作的。当你完全理解了它的思想，你就可以按照自己的喜好随意优化架构。
06 无奈的没落
回想起大学那会刚接触MVP时真的被惊艳到了，不同类别的逻辑代码被划分的井井有条，可是随着时间的慢慢推移，MVP的缺陷也越来越明显，那就是代码太过冗余，尽管我们尝试使用各种奇淫巧技来消除样板代码，可还是不太优雅。
随着近几年MVVM的横空出世，以及Android官方推出的全新架构组件都在标志着MVP已经渐渐远离主流的项目搭建。
说到这里让我不禁的想起世界杯解说中的一句话：
人生有多少个十年，可以陪伴一个人的所有高峰与低谷，可是当我站立在人潮中，看千百双手挥舞，却再也看不到你的影踪。
虽然我们需要更高效更完美的架构，但是更应该把MVP带给我们的架构思想以及深处的精髓留在心中，将来无论遇到什么框架，对逻辑美的执念会帮助我们走的更远。