通过MVC与MVP的对比，简述单一职责原则

本文将通过MVC与MVP模式分析，粗略简述单一职责原则，日后有机会，会进一步进行分析探讨六大基本原则。

MVC

MVP

通过上述两张图可以很明显的看出MVP在MVC的基础上进行解耦，再次不做多余的分析，先简单看一个例子，点击按钮后，从0到1000进行相加，得到结果后先赋值给model，再把model的值在textview上显示。

public class MainModel
{
    public int value;
}

/**
 * 
 * Created by zero on 2016-05-26
 *
 */
public class MainActivity extends AppCompatActivity {

    private Button btn_click;
    private TextView txt_value;
    private MainModel model;
    private int count = 0;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        btn_click = (Button) findViewById(R.id.btn_click);
        txt_value = (TextView) findViewById(R.id.txt_value);
        btn_click.setOnClickListener(new OnClickListener()
        {

            @Override
            public void onClick(View v) {
                // TODO Auto-generated method stub
                for (int i = 0; i <= 1000; i++)
                {
                    count+=i;
                }
                model.value = count;
                txt_value.setText(model.value+"");
            }
        });
    }
}

由此可以看出view的展示和更新，还有业务逻辑的处理写在了MainActivity里面，把传统的MVC运用到Android中，由于activity和fragment即是V层也是C层，如下图所示：

当UI很复杂且业务逻辑很繁琐的情况下，可能会导致activity或者fragment非常庞大且臃肿，当需要改动、添加或者维护一个功能的时候，给我们的开发带来了很大的不便。我曾经通过反编译看到过一个公司的源码，其中一个activity达到近万行代码，当时我就吓尿了，对于这样的代码，就算把源代码抛向市场也是安全的，谁TM愿意花那么多时间去研究一个近万行的activity，而且这只是其中的一个。。。

接下来，我们再看一下MVP，MVP可以说是源于MVP，在遵循单一职责原则的基础上将MVC进一步解耦，在Presenter中，只负责业务逻辑的处理，在View层，只是负责UI的展示和更新，我们在使用MVP去完成上述代码，如下所示：

/**
 * 好的开发者会先理清当前逻辑，面向接口编程，而不是边写边改接口
 * @author zero
 *
 */
public interface IMain
{
    public void sendResult(int result);
}

/**
 * Google官方建议使用public取代get/set，在listview或者
 * recyclerview快速读取数据的时候避免丢帧
 * 
 * @author zero
 * 
 */
public class MainModel
{
    public int value;
}

/**
 * 业务逻辑的处理
 * @author zero
 *
 */
public class MainPresenter
{
    private IMain iView;
    private int count = 0;
    private MainModel model;
    public MainPresenter(IMain iMain)
    {
        // TODO Auto-generated constructor stub
        this.iView = iMain;
    }

    public void summation(){
        for (int i = 0; i <= 1000; i++)
        {
            count +=i;
        }
        //实际应用中，model中的字段可能会很多，用来接收json
        model.value = count;
        //把得到的结果发送给View层，提示更新UI
        iView.sendResult(model.value);
    }
}

/**
 * 仅仅负责展示和更新UI
 * Created by zero on 2016-05-26
 *
 */
public class MainActivity extends AppCompatActivity implements IMain{

    private Button btn_click;
    private TextView txt_value;
    private MainPresenter presenter;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
        presenter = new MainPresenter(this);
        btn_click = (Button) findViewById(R.id.btn_click);
        txt_value = (TextView) findViewById(R.id.txt_value);
        btn_click.setOnClickListener(new OnClickListener()
        {

            @Override
            public void onClick(View v) {
                // 把业务逻辑转移到presenter中
                presenter.summation();
            }
        });
    }

    @Override
    public void sendResult(int result) {
        // 接收presenter的值，更新UI
        txt_value.setText(result+"");
    }
}

通过上述分析，我们再把焦点重新转移到单一职责原则，单一职责原则（Single Responsibility Principle），简称SRP。就一个类而言，应该仅有一个引起它变化的原因。如果一个类承担的职责太多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或抑制这个类完成其它职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭到意想不到的破坏。

接下来会运用一些开发中的具体实例来讲述单一职责原则。

参考文献：《大话设计模式》