前言

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

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

为什么需要封装？

1. 减少类似代码，使父子类代码结构优雅。
   app中普遍有设计BaseActivity，BaseFragment基类，将mvp中view层的类似代码也抽取到其当中，无疑是更好的选择。
2. 优化代码编写步骤。
   完成封装之后，得首先编写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<T,E>{
  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> T getT(Object o, int i) {
    try {
      return ((Class<T>) ((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基类封装的理解与思考，如果觉得我写的不错的，点个喜欢吧！

Android MVP架构模式基类封装