设计模式：从mvc到mvp

mvc与mvp概述

MVP是Model(数据) View(界面) Presenter(表现层)的缩写，它是MVC架构的变种，强调Model和View的最大化解耦和单一职责原则
Model：负责数据的来源和封装，比如网络请求类，数据库操作类以及java bean，如果有必要则提供接口暴露自己处理数据的状态和进度。
View：负责UI相关，如布局UI的初始化，各种listener的设置。在Android中，我们通常写的Activity和Fragment就是属于View层；在web开发中，html则是View层。
Controller：业务逻辑控制器，主要负责当获取到数据后对数据进行逻辑处理，然后将数据绑定到View上；比如：请求一个url，从网络获取到数据，进行解析javabean，然后各种set数据。对于控制器的概念大家很好理解，因为我们每天都在这样做，在Activity中请求数据然后更新UI。但是结合View的概念来看，很显然Activity和Fragment不但承担了View的任务，还负责完成的Controller的功能，随着业务功能的增多，Activity的代码越来越难以阅读和维护，这就是在Android中使用MVC的弊端，为了解决MVC模式下View层的臃肿，MVP模式应运而生。
Presenter：专门从C独立出来的业务逻辑层，主要负责处理原先View层的业务逻辑，解决了Activity的臃肿问题，让Activity只负责处理UI，职责更加明确；并且将View层的业务逻辑抽取到P层之后，View层与Model层也实现了解耦；便于后期代码的扩展和维护,并且业务逻辑层独立后代码还得到很大的重用性。
下面我用具体的代码的实例来分析，我以项目中的登录模块作为例子：
这里我啰嗦俩句吧：初学者可能会错误的认为MVP模式就是把数据层的代码写在modle包下面，界面写在view，业务逻辑写在presenter包中，MVP架构也就仅此而已，在此我需要特别强调一点的就是：
即使你进行的 分包，但是你的类之间互相持有对方的引用（就是在类内部互相new），互相依赖，那么分不分包是没有丝毫意义的，
就跟java语言中的封装一样，如果你写了个phone类，却又担负起照相、看电影等责任，那么谈抽象，谈封装就没什么意义。或者，写了一个照相的方法，还要把修照片的等多个功能也加在这个方法里，那么这个方法也就仅仅这当前用而已。
对于一个程序员来说，最重要的不是看代码逻辑，而要把更多的注意力放在代码优化，很多程序员不知道自己努力的方向吗，而说起来很简单，就是下面几句话：
如何让自己的代码 低藕合，高复用，易测试，好维护

mvc回顾

好了，继续MVP模式的讲解，为了更好的理解MVP，我先通过具体代码回顾下mvc，然后对比mvp，先用一个mvc设计模式写一个登录逻辑代码。

public class LoginActivity extends AppCompatActivity {

    @InjectView(R.id.username)
    EditText etUsername;
    @InjectView(R.id.pwd)
    EditText etPwd;
    @InjectView(R.id.activity_login)
    LinearLayout activityLogin;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_login);
        ButterKnife.inject(this);
    }

    // 登录按钮的点击事件
    @OnClick(R.id.activity_login)
    public void onClick() {
        // 1、获取输入框的数据
        String username = etUsername.getText().toString().trim();
        String pwd = etPwd.getText().toString().trim();

        // 2、 检查用户输入的合法性
        if(checkInput(username, pwd)){
            // 3、 执行登录操作
            String url = "www.baidu.com";
            HttpUtil.getInstance().post(url, new   HttpUtil.HttpUtilCallBack() {
                @Override
                public void onSuccess(String response) {
                    // 4、登录成功，保存用户数据
                    saveUserInfo();
                    // 5、跳转界面
                    jumpActivity();
                }

                @Override
                public void onFail(String errorInfo) {
                    // 登录失败
                }
            });
        }

    }

    private boolean checkInput(String username, String pwd) {
        if(TextUtils.isEmpty(username) && TextUtils.isEmpty(pwd)){
            showEmptyInfo();
            return false;
        }
        if(username.length() != 11){
            showLenthErrorInfo();
            return false;
        }
        return true;
    }

    private void showEmptyInfo() {
        Toast.makeText(this, "用户名或密码不能为空", Toast.LENGTH_SHORT).show();
    }


    private void showLenthErrorInfo() {
        Toast.makeText(this, "用户名长度不正确", Toast.LENGTH_SHORT).show();
    }

    private void saveUserInfo() {
    }

    private void jumpActivity() {
    }

}

下面是我虚拟的一个网络请求，就是我们Model层的代码

public class HttpUtil {
    private HttpUtil() {}
    private static HttpUtil httpUtil = new HttpUtil();
    public static HttpUtil getInstance(){
        return httpUtil;
    }

    public void post(String url, HttpUtilCallBack callBack){
       ......
    }

    public interface HttpUtilCallBack{
        void onSuccess(String response);
        void onFail(String errorInfo);
    }
}

从上面的代码中可以看到，MVC模式下弊端，很显然Activity不但承担了View的任务，还负责完成的Controller的功能，随着业务功能的增多，Activity的代码越来越难以阅读和维护，这就是在Android中使用MVC的弊端。

从mvc中抽取出p层

下面从上面的Activity中抽取出一个P 层，继续来看代码，我们不去动原来的Mode层。 很简单的抽取出一个p(LoginPresenter)层，把业务逻辑放到p层中，原来的LoginActivity仅仅作为一个View
下面是抽取后的LoginActivity的代码：

public class LoginActivity extends AppCompatActivity{

    @butterknife.InjectView(R.id.username)
    EditText etUsername;
    @butterknife.InjectView(R.id.pwd)
    EditText etPwd;
    @butterknife.InjectView(R.id.activity_login)
    LinearLayout activityLogin;

    private LoginPresenterImpl mLoginPresenterImpl;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_login);
        butterknife.ButterKnife.inject(this);

        mLoginPresenterImpl = new LoginPresenterImpl(this);
    }

    @butterknife.OnClick(R.id.activity_login)
    public void onClick() {
        String username = etUsername.getText().toString().trim();
        String pwd = etPwd.getText().toString().trim();

        mLoginPresenterImpl.login(username, pwd);
    }

    public void showEmptyInfo() {
        Toast.makeText(this, "用户名或密码不能为空", Toast.LENGTH_SHORT).show();
    }


    public void showLenthErrorInfo() {
        Toast.makeText(this, "用户名长度不正确", Toast.LENGTH_SHORT).show();
    }
}

先不看LoginPresneter的代码，也先不去看MVC中LoginActivity中的代码，就看MVP中的Activity，仅仅作为了一个View界面的展示，明白了这一点，可以去对比MVC中的LoginActivity了，看看那些地方改动。对比之后，下面贴出抽取出的P层代码：

public class LoginPresenterImpl  {
    private LoginActivity mLoginActivity;

    public LoginPresenterImpl(LoginActivity loginActivity) {
        mLoginActivity = loginActivity;
    }

    public void login(String username, String pwd) {
        // 2、 检查用户输入的合法性
        if(checkInput(username, pwd)){
            // 3、 执行登录操作
            String url = "www.baidu.com";
            HttpUtil.getInstance().post(url, new HttpUtil.HttpUtilCallBack() {

                @Override
                public void onSuccess(String response){
                    // 保存用户信息
                    saveUserInfo();
                    // 界面跳转
                    jumpActivity();
                }

                @Override
                public void onFail(String errorInfo) {
                }
            });
        }
    }

    private boolean checkInput(String username, String pwd) {
        if(TextUtils.isEmpty(username) && TextUtils.isEmpty(pwd)){
            mLoginActivity.showEmptyInfo();
            return false;
        }
        if(username.length() != 11){
            mLoginActivity.showLenthErrorInfo();
            return false;
        }
        return true;
    }

    private void saveUserInfo() {
    }

    private void jumpActivity() {
    }
}

看以看到业务逻辑的代码在LoginPresneter中。
但是，还是有很大的不足，耦合性太强，我们仔细分析代码就可以看到，在LoginActivity中有创建了一个LoginPresenter实例，而在LoginPresenter中创建了一个LoginActivity实例对象，V层和P之间互相依赖，谈何 低藕合，高复用，易测试的模块化设计。

p层和v层实现解耦操作

下面我们对P层和V层进行一个解耦操作，首先，创建一个LoginActivity的接口类，这个类里面，主要是一些P层业务逻辑代码执行结果的回调。

我们看到在P层和V层明显多了一个借口，
先来看看我们的LoginPresenter接口里面的代码

public interface LoginPresenter {
    void login(String username, String pwd);
}

没错，就是把原来的Presnter类里面的业务方法进行了统一的规制声明
而LoginView借口里面则是业务逻辑执行结果的一些回调。

public interface LoginView {
    void onLoginState(boolean success, String msg);
}

下面是新的LoginPresenterimpl的代码

public class LoginPresenterImpl  implements LoginPresenter{
    private LoginView mLoginView;

    public LoginPresenterImpl(LoginView loginView) {
        mLoginView = loginView;
    }

    public void login(String username, String pwd) {
        // 2、 检查用户输入的合法性
        if(checkInput(username, pwd)){
            // 3、 执行登录操作
            String url = "www.baidu.com";
            HttpUtil.getInstance().post(url, new HttpUtil.HttpUtilCallBack() {

                @Override
                public void onSuccess(String response){
                    mLoginView.onLoginState(true, response); // 业务逻辑执行成功的回调
                    // 保存用户信息
                    saveUserInfo();
                    // 界面跳转
                    jumpActivity();
                }

                @Override
                public void onFail(String errorInfo) {
                    mLoginView.onLoginState(false, errorInfo); // 业务逻辑执行失败的回调
                }
            });
        }
    }

    private boolean checkInput(String username, String pwd) {
        if(TextUtils.isEmpty(username) && TextUtils.isEmpty(pwd)){
            return false;
        }
        if(username.length() != 11){
            return false;
        }
        return true;
    }

    private void saveUserInfo() {
    }

    private void jumpActivity() {
    }
}

可以很清楚的看到，现在LoginPresenterImpl类里面不再有LoginActivity的引用，而仅仅是一个LoginView的接口，LoginPresenterImpl就不仅仅属于LoginActivity，而属于所有实现了LoginView接口的类。实现了LoginPresenter的解耦，下面再看LoginActivity里面的代码呢

public class LoginActivity extends AppCompatActivity implements LoginView{

    @butterknife.InjectView(R.id.username)
    EditText etUsername;
    @butterknife.InjectView(R.id.pwd)
    EditText etPwd;
    @butterknife.InjectView(R.id.activity_login)
    LinearLayout activityLogin;

    private LoginPresenter mLoginPresenter;
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_login);
        butterknife.ButterKnife.inject(this);

        mLoginPresenter = new LoginPresenterImpl(this);
    }

    @butterknife.OnClick(R.id.activity_login)
    public void onClick() {
        String username = etUsername.getText().toString().trim();
        String pwd = etPwd.getText().toString().trim();

        mLoginPresenter.login(username, pwd);
    }

    public void showEmptyInfo() {
        Toast.makeText(this, "用户名或密码不能为空", Toast.LENGTH_SHORT).show();
    }


    public void showLenthErrorInfo() {
        Toast.makeText(this, "用户名长度不正确", Toast.LENGTH_SHORT).show();
    }

    @Override
    public void onLoginState(boolean success, String msg) {
        if(success){
            // 登录成功
        } else {
            // 登录失败
        }
    }
}

对，大家看到了，在LoginActivity还是创建了Loginpresneterimpl的实例对象，还是没有实现彻底的解耦。而我要说的mvp模式，到这里也基本结束，这个具体解释看完下面的总结，大家应该能理解。

总结

对MVP模式，每个人都有自己的理解，谷歌官方也给出了MVP代码，谷歌对MVP的理解把Acitivity看成一个数据、界面。控制器之外的另一个控制器，仅仅控制自己生命周期，仅此而已，而界面View展示则交给fragment去展示。但是没有太多人去跟随谷歌，
大多数人还是把Activity看成是一个View，包括我也一样。mvp有优点，也有缺点，优缺点在我上面代码从mvc到mvp一个过程也一目了然,一路下来，功能还是那个功能，当时类却暴增，仅仅一个登陆模块，就需要这么类，对于一些中小型项目来说，使用mvp未免让项目更加复杂了，要是再去为继续解耦，就得继续往上抽取，在上层进行一个对象的实例化，像谷歌那样，还要为每一个Activity创建一个Fragment，那创建的类还是要更多，所以，上面解耦操作到此为适中。
当然，以上只是个人对mvp的理解。