从 MVP学习代码封装 (2) - 搭建 MVP 最基础框架

2017-11-25 本文已影响69人前行的乌龟

本系列文章集合：从 MVP学习代码封装 (1) - 综述

MVP 我就不说了，前面的章节说过了，我也相信能看到这里的萌新们对于 MVP 应该都熟记于心了，无需多言。作为我们代码封装的开始，我们先来熟悉代码封装的简单套路，这里涉及到的是最简单的封装套路，是基础，不怎么涉及到设计模式。

这个模式就是：base 接口 —> abs 基类 —> 实现类

最基本的代码封装套路都是这个样子：

base 接口的意思在于定于基础功能方法，使用设计模式中 - 依赖倒置原则，作为对外暴露的统一类型使用，常见使用的范围就是泛型传递了。
abs 基类的意思在于封装公共方法和参数，主要是从代码复用教导出发
实现类，不用说了，具体的类，继承 abs 基类

下面我会一部一部的记录代码封装的过程和思考，尽量详细，力求给萌新们提供有用的帮助

项目地址： BW-MVPDemo

需要说一下，每个modle 都是可以独立运行的，step1 的 modle 都是本节文章的，没有 step1_4，我写的时候把 #3 和#4写一起了，大家注意下。

#1 我们简单建立一个 MVP 的结构

因为很简单，原始，大家都会，我就不上代码了，直接 UML 走起了，自己画的，可能不是很好看，大家见谅啊。数据层先简单的用一个字符串代替，后面会跑真实数据接口

Snip20171125_36.png

IBaseView - ui 接口的 updata 方法就是更新数据显示方法

#2 处理 P 层持有V 层对象可能造成的内存泄露

这里我们首先规范 P 层与 V 层的绑定和解绑，然后同步 V 层的生命周期

Snip20171125_37.png

#3 抽象 P 层的公共代码

在上面我们给 P 层添加了和 V 层绑定，解绑的方法，这个方法每个 P 层的类都会用到的，拿着这2个方法就是重复代码，公共方法，是我们需要优化的，所以这里我们添加 P 层的抽象基类 (BasePersenter)，封装公共方法

Snip20171125_38.png

#4 P 层引入泛型，支持动态 V 层对象类型

不要忘了我们封装代码的初衷，更简单，更好用，更好看，更好改。我们虽然抽象了 P 层的 abs 基类，但是持有的 V 层对象类型是 V 层的根base 接口类型，在具体的 P 对象中还是要把 V 层对象类型转换成我们需要的具体的 V 层对象类型，这一步V 层对象的类型转换，其实本质上也是重复代码，只不过是代码量很少，但是我要说我们一定要根本一颗尽善尽美的心，才能越做越好。这是题外话了，切回正题，频繁的类型转换会让我们在编码时不是很灵活，而且类型转换写多了可能你让我们有点晕

所以本着尽自己最大努力的想法，这里引入动态类型传递 - 泛型。这里我就要加上点代码了，泛型使用还是有些需要说的

Snip20171126_40.png

abs P层基类

public abstract class BasePersenter<V extends IBaseView> {

    protected V mIBaseView;

    public void attachView(V baseViewa) {
        this.mIBaseView = baseViewa;
    }

    public V getView() {
        return mIBaseView;
    }

    public void detachView() {
        this.mIBaseView = null;
    }
}

P层具体实现类

public class NewsPersenter extends BasePersenter<IBaseView> {
    .......
}

放上代码是为了看泛型使用的，具体的代码没什么，想看的去看 demo

#5 抽象 V 层的公共代码， V 层引入泛型，支持动态 V，P 层对象类型

P 层我们抽象了 abs 基类，那么同样 V 层我们也是需要抽象 V 层的 abs 基类，activiyt 的公共方法和参数有很多的。

另外在我们抽象的 V 层的 abs 基类中，P 层对象的类型也是不确定的，这里我们同样要在 V 层中使用泛型动态类型，这里需要注意，我们在 P 层abs 基类已经使用了 V 层对象的泛型，所以在写 V 层中 P 层对象的泛型类型时要注意类型传递，因为 V 层的接口根据实际业务可能会有很多层，这里我就多加了一层 view 接口

Snip20171126_41.png

V 层的abs 基类

public abstract class BaseActivity<V extends IBaseView, P extends BasePersenter<V>> extends AppCompatActivity implements IBaseView {

    public P mBasePersenter;

    protected abstract P createPersenter();

    public P getPersenter() {
        if (mBasePersenter == null) {
            mBasePersenter = createPersenter();
        }
        return mBasePersenter;
    }

    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        mBasePersenter = createPersenter();
        mBasePersenter.attachView((V) this);
    }

    @Override
    protected void onDestroy() {
        if (mBasePersenter != null) {
            mBasePersenter.detachView();
        }
        super.onDestroy();
    }
}

V 层的具体实现类

public class NewsActivity extends BaseActivity<INewsView, NewsPersenter> implements INewsView {

    private TextView tx_content;
    private Button btn_getNews;

    @Override
    protected NewsPersenter createPersenter() {
        return new NewsPersenter();
    }

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        tx_content = (TextView) findViewById(R.id.content);
        btn_getNews = (Button) findViewById(R.id.title);

        btn_getNews.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                if (getPersenter() != null) {
                    getPersenter().update();
                }
            }
        });
    }

    @Override
    public void update(String data) {
        tx_content.setText(data);
    }

    @Override
    public void showNewsList() {
    }
}

在 BaseActivity 中，使用了2个泛型，一个是 V层的具体子类的类型，一个是 P 层的类型，因为 P 层的 bas 基类需要填入 V 层对象的实现类型，所以在 BaseActivity 这个 V 层的 abs 基类中需要知道具体的实现子类的类型，以方便传递给 P 层,所以泛型写成这样，萌新们注意啊，我刚接触时这里也是理解了一段时间的

public abstract class BaseActivity<V extends IBaseView, P extends BasePersenter<V>> extends AppCompatActivity implements IBaseView

另外注意这里：

   mBasePersenter = createPersenter();
   mBasePersenter.attachView((V) this);

在 P 对象绑定 V 对象时，其实这里因为分别对 P,V 使用了泛型的缘故，这里实际上都是实际的实现类了，需要强转 V 的类型为实现类类型

这一点还有需要注意接口实现的传递性，abs 基类实现 V 层的根业务接口，V 层实现类需要实现具体业务接口，具体业务接口是继承自V 层的根业务接口的，哈哈，说的有点像绕口令了，我也这么觉得，反正这些都是涉及的类型的问题，因为用了泛型，所以这种具体类型和跟类型之间的转换肯定是少不了的，大家多多站在这里注意啊，这里很容易出问题的，类多了就很绕了。

INewsView -> IBaseView 

BaseActivity -> implements IBaseView 
NewsActivity-> implements INewsView {

#6 使用动态代理处理 v 对象的非空判断

不知道大家用没用过动态代理啊，动态代理是可以代理目标对象中的任何方法，感觉和 hook 很像。这里我们目前只能对 P层中的 V层对象做动态代理，而不能对V 层中 P 层对象做代理，因为动态代理需要目标对象实现一个接口，基类不行。


public abstract class BasePersenter<V extends IBaseView> {

    protected V mIBaseView;

    protected void getProxyView() {
        mIBaseView = (V) Proxy.newProxyInstance(mIBaseView.getClass().getClassLoader(), mIBaseView.getClass().getInterfaces(), new NotNullnvocationHandler(mIBaseView));
    }

    public void attachView(V baseView) {
        this.mIBaseView = baseView;
        getProxyView();
    }

    public V getView() {
        return mIBaseView;
    }

    public void detachView() {
        this.mIBaseView = null;
    }

    public class NotNullnvocationHandler implements InvocationHandler {

        protected V v;

        public NotNullnvocationHandler(V v){
            this.v = v;
        }

        @Override
        public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {

            if (mIBaseView == null) {
                return null;
            }
            return method.invoke(v, args);
        }
    }
}

这样我们在 getView() 时就不用进行非空判断了。

#7 添加对 fragment / 自定义 viewGroup 的支持

上面我们提供了 activity 对应mvp 实现，但是我们还有 fragment / 自定义 viewGroup 啊，这2个我们也是经常用的啊，在 mvp 架构方面看其实 fragment / 自定义 viewGroup 和 avtiviyt 没什么不同的，区别的是不同的 UI 组件罢了，他们在 mvp 中处于的位置相同，包含的属性和功能应该也是相同的才对

Snip20171203_47.png

类多了我就真心不会画 UML 类图了

BaseActivity:

public abstract class BaseActivity<V extends IBaseView, P extends BasePersenter<V>> extends AppCompatActivity implements IBaseView {

    private P mBasePersenter;

    protected abstract P createPersenter();

    public P getPersenter() {
        return mBasePersenter;
    }

    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        mBasePersenter = createPersenter();
        mBasePersenter.attachView((V) this);
    }

    @Override
    protected void onDestroy() {
        if (mBasePersenter != null) {
            mBasePersenter.detachView();
        }
        super.onDestroy();
    }

}

BaseFragment

public abstract class BaseFragment<V extends IBaseView, P extends BasePersenter<V>> extends Fragment implements IBaseView {

    private P mBasePersenter;

    protected abstract P createPersenter();

    public P getPersenter() {
        return mBasePersenter;
    }

    @Override
    public void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        mBasePersenter = createPersenter();
        mBasePersenter.attachView((V) this);
    }

    @Override
    public void onDestroy() {
        if (mBasePersenter != null) {
            mBasePersenter.detachView();
        }
        super.onDestroy();
    }

}

BaseCustomeView:

public abstract class BaseCustomeView<V extends IBaseView, P extends BasePersenter<V>> extends AppCompatButton implements IBaseView {

    private P mBasePersenter;
    private onCustomeClickListener customeClickListener;

    protected abstract P createPersenter();

    public P getPersenter() {
        return mBasePersenter;
    }

    @Override
    public void update(String data) {

    }

    public BaseCustomeView(Context context) {
        super(context);
    }

    public BaseCustomeView(Context context, @Nullable AttributeSet attrs) {
        super(context, attrs);
    }

    public BaseCustomeView(Context context, @Nullable AttributeSet attrs, int defStyleAttr) {
        super(context, attrs, defStyleAttr);
    }

    public void setCustomeClickListener(onCustomeClickListener customeClickListener) {
        this.customeClickListener = customeClickListener;
    }

    @Override
    protected void onFinishInflate() {
        super.onFinishInflate();
        mBasePersenter = createPersenter();
        mBasePersenter.attachView((V) this);
    }

    @Override
    public void setOnClickListener(@Nullable final OnClickListener l) {

        super.setOnClickListener(new OnClickListener() {
            @Override
            public void onClick(View v) {
                if (customeClickListener != null) {
                    customeClickListener.onCustomeClick(v);
                }
                l.onClick(v);
            }
        });
    }

    @Override
    protected void onDetachedFromWindow() {
        if (mBasePersenter != null) {
            mBasePersenter.detachView();
        }
        super.onDetachedFromWindow();
    }

    public interface onCustomeClickListener {

        void onCustomeClick(View view);

    }

}

说真心话，写 BaseFragment / BaseCustomeView 我都是直接复制粘贴的BaseActivity 的代码，说到这里各位看官应该也知道了，我们下一步该干什么了吧。

我最想说的

代码抽象问题：
看到这里，大家对于上面我说的那个问题 “ 说到这里各位看官应该也知道了，我们下一步该干什么了吧 ” ，大家怎么看，一般认为我们对于 BaseActivity / BaseFragment / BaseCustomeView 中重复的代码应该再抽象一下，再抽象出一个顶层 abs 基类出来，我一开始第一反应就是这样，也去这样写了，但是呢我写不出来，为啥？大家想没想过，aseActivity / BaseFragment / BaseCustomeView 都是我们对应不同类型的系统UI 组件类型才分离出来的，天然就要去继承 Activity / Fragment / View 这3个系统类，然后基于 java 继承的单一性，我们怎么再去继承一个类呢，我们写的已经是抽象类了，是要给我们自己的 Activity / Fragment / View 去继承的。也许有人要说，我们可以使用装饰着设计模式啊，使用一个 wrapper 容器类来添加功能啊，但是我要说不合适这里，我们要是使用了容器类，那么我们的 abs 基类就不再是 Activity / Fragment / View。所以我想说呢，大部分重复代码是可以通过封装来省略的，但是有的不行，不要因为封装去封装，封装的根本目的还是优化我们现有的代码结构，一切以实际需求为准，简单好用，不复杂才是真的好。
接口继承和泛型类型限定问题：
不知道大家对 IBaseView这个 view 层的根接口有没有想过，为啥我们在写 INewsView 这个具体的 V 层业务接口的时候，我们要去继承 IBaseView 呢。因为我们限定了 BaseActivity<V extends IBaseView, P extends BasePersenter<V>> 的泛型 V 的取值范围，在我们写一个具体的 activity 时，NewsActivity extends BaseActivity<INewsView, NewsPersenter> 我们想要在 NewsPersenter 中操作的即是 INewsView 这个业务接口，也是 IBaseView 这个 V 层视图对象，所以我们让V 的业务接口继承跟接口： INewsView extends IBaseView 。当然还有另一种写法，对于 BaseActivity，BasePersenter 中的 V 泛型不做任何限制，这样写也行，但是失去了泛型可以实现的类型验证功能，我不太喜欢，这点还是仁者见仁，智者见智吧，没有一定正确的，只有大家的个人喜好和具体需求的适应性了，能适应好具体需求，达到易扩展，好维护，就是好代码。

从 MVP学习代码封装 (2) - 搭建 MVP 最基础框架

#1 我们简单建立一个 MVP 的结构

#2 处理 P 层持有V 层对象可能造成的内存泄露

#3 抽象 P 层的公共代码

#4 P 层引入泛型，支持动态 V 层对象类型

#5 抽象 V 层的公共代码， V 层引入泛型，支持动态 V，P 层对象类型

#6 使用动态代理处理 v 对象的非空判断

#7 添加对 fragment / 自定义 viewGroup 的支持

我最想说的

参考资料：

猜你喜欢

热点阅读

从 MVP学习代码封装 (2) - 搭建 MVP 最基础框架

#1 我们简单建立一个 MVP 的结构

#2 处理 P 层持有V 层对象可能造成的内存泄露

#3 抽象 P 层的公共代码

#4 P 层引入泛型，支持动态 V 层对象类型

#5 抽象 V 层的公共代码 ， V 层引入泛型，支持动态 V，P 层对象类型

#6 使用动态代理处理 v 对象的非空判断

#7 添加对 fragment / 自定义 viewGroup 的支持

我最想说的

参考资料：

猜你喜欢

热点阅读

#5 抽象 V 层的公共代码， V 层引入泛型，支持动态 V，P 层对象类型