前言

MVP模式是Android官方推荐的架构模式，可使视图与数据层完全解耦。本文旨意封装在MVP模式中的基类如Activity，Fragment，Presenter类。

以下内容建议在了解了mvp模式的读者阅读，如果还有对mvp架构模式有疑问的，请看我的另外一篇文章《Android MVP架构模式初窥门径》

为什么需要封装？

减少类似代码，使父子类代码结构优雅。

app中普遍有设计BaseActivity，BaseFragment基类，将mvp中view层的类似代码也抽取到其当中，无疑是更好的选择。

优化代码编写步骤。

完成封装之后，得首先编写Model类，其次Presenter类，最后才是View类，符合“从数据下手”思想，在编写View类时不会有无从下手的错觉。

说完了基类封装mvp模式的优点，下面开始我们来看看代码中是如何实现的。

- BaseModel

由于model层大多是数据跟业务逻辑处理，个个model接口与实现类可以说是层出不穷，下面只抽取大部分model类都会遇到的场景，即访问网络的失败回调。

public interface BaseModel{

void onFailed(String error);

}

- BaseView

BaseView相对来说更加灵活，一千个读者心里有一千个BaseView。所以下面只给出参考案例。

public interface BaseView{

void onLoaded();

void onLoading();

void onLoadFailed(String error);

}

- BasePresenter

在presenter层中，我们一般要从外获取对应view层以及model层的实例，从而在该类中进行各种操作，为了追求更直接，省去转型的封装方式，我们使用泛型来规定BasePresenter中的view及model实例字段。

public abstract class BasePresenter{

public T mModel;

public E mView;

public void setVM(T t,E e){

this.mModel = t;

this.mView = e;

}

}

- BaseActivity / BaseFragment

在视图层中我们不难发现，在该模式下的activity/fragment中都会有对应presenter的引用，通过该引用设置view层接口。这一块转个方向也是可以抽取封装的，同样用泛型代替。

public abstract class BaseActivity< T extends BasePresenter, E extends BaseModel> extends Activity {

public T mPresenter;

@Override

public void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

setContentView(getLayoutId());

this.initPresenter();

this.initView();

}

public abstract void initPresenter();

public abstract void initView();

public abstract int getLayoutId();

}

public abstract class BaseFragment< T extends BasePresenter, E extends BaseModel> extends Fragment{

public T mPresenter;

public View mView;

@Override

public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {

super.onCreate(inflater,container,savedInstanceState);

mView = inflater.inflate(getLayoutResource(), container, false);

mPresenter = TUtil.getT(this, 0);

this.initPresenter();

this.initView();

return mView;

}

public abstract void initPresenter();

public abstract void initView();

public abstract int getLayoutResource();

}

为了子类能够灵活的使用或不使用mvp模式，presenter引用的初始化交给需要设计成mvp模式的部分子类(第二个this指实现了BaseView接口)去处理：

...

@Override

public void initPresenter(){

//需要设计成mvp直接加下句代码 不需要则不理会

mPresenter.setVM(TUtil.getT(this,1),this);

}

...

我想读者看到这里肯定在想这个神秘的TUtil是什么呢？其实就是基于反射+泛型的类转换类，拿到最外层的<>里的参数数组然后根据索引获取实例的工具类。

/**

* 类转换初始化

*/

public class TUtil {

public static T getT(Object o, int i) {

try {

return ((Class) ((ParameterizedType) (o.getClass()

.getGenericSuperclass())).getActualTypeArguments()[i])

.newInstance();

} catch (InstantiationException e) {

e.printStackTrace();

} catch (IllegalAccessException e) {

e.printStackTrace();

} catch (ClassCastException e) {

e.printStackTrace();

}

return null;

}

}

总结

通过对mvp模式基类的封装，加上契约类的管理，可以使项目整体框架代码结构优雅，页面各层设计一目了然。(对契约类不是很了解的，可以看我的另一篇文章：《Android MVP架构模式初窥门径》)

以上就是本人对mvp基类封装的理解与思考，如果觉得我写的不错的，点个喜欢吧！

图片发自简书App