本系列文章集合：从 MVP学习代码封装 (1) - 综述
MVP 我就不说了，前面的章节说过了，我也相信能看到这里的萌新们对于 MVP 应该都熟记于心了，无需多言。作为我们代码封装的开始，我们先来熟悉代码封装的简单套路，这里涉及到的是最简单的封装套路，是基础，不怎么涉及到设计模式。
这个模式就是：base 接口 —> abs 基类 —> 实现类
最基本的代码封装套路都是这个样子：
- base 接口的意思在于定于基础功能方法，使用设计模式中 - 依赖倒置原则，作为对外暴露的统一类型使用，常见使用的范围就是泛型传递了。
- abs 基类的意思在于封装公共方法和参数，主要是从代码复用教导出发
- 实现类，不用说了，具体的类，继承 abs 基类
下面我会一部一部的记录代码封装的过程和思考，尽量详细，力求给萌新们提供有用的帮助
项目地址： BW-MVPDemo
需要说一下，每个modle 都是可以独立运行的，step1 的 modle 都是本节文章的，没有 step1_4，我写的时候把 #3 和#4写一起了，大家注意下。
#1 我们简单建立一个 MVP 的结构
因为很简单，原始，大家都会，我就不上代码了，直接 UML 走起了，自己画的，可能不是很好看，大家见谅啊。数据层先简单的用一个字符串代替，后面会跑真实数据接口
- IBaseView - ui 接口的 updata 方法就是更新数据显示方法
#2 处理 P 层持有V 层对象可能造成的内存泄露
这里我们首先规范 P 层与 V 层的绑定和解绑，然后同步 V 层的生命周期
#3 抽象 P 层的公共代码
在上面我们给 P 层添加了和 V 层绑定，解绑的方法，这个方法每个 P 层的类都会用到的， 拿着这2个方法就是重复代码，公共方法，是我们需要优化的，所以这里我们添加 P 层的抽象基类 (BasePersenter)，封装公共方法
#4 P 层引入泛型，支持动态 V 层对象类型
不要忘了我们封装代码的初衷，更简单，更好用，更好看，更好改。我们虽然抽象了 P 层的 abs 基类，但是持有的 V 层对象类型是 V 层的 根base 接口类型，在具体的 P 对象中还是要把 V 层对象类型转换成我们需要的具体的 V 层对象类型，这一步V 层对象的类型转换，其实本质上也是重复代码，只不过是代码量很少，但是我要说我们一定要根本一颗尽善尽美的心，才能越做越好。这是题外话了，切回正题，频繁的类型转换会让我们在编码时不是很灵活，而且类型转换写多了可能你让我们有点晕
所以本着尽自己最大努力的想法，这里引入动态类型传递 - 泛型。这里我就要加上点代码了，泛型使用还是有些需要说的
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 接口
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 中处于的位置相同，包含的属性和功能应该也是相同的才对
类多了我就真心不会画 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 泛型不做任何限制，这样写也行，但是失去了泛型可以实现的类型验证功能，我不太喜欢，这点还是仁者见仁，智者见智吧，没有一定正确的，只有大家的个人喜好和具体需求的适应性了，能适应好具体需求，达到易扩展，好维护，就是好代码。
