Android设计原则——单一职责原则
一、什么是单一职责原则单一职责原则（SRP：Singleresponsibilityprinciple）...
一、什么是单一职责原则
单一职责原则（SRP：Single responsibility principle）又称单一功能原则，其定义为：一个类，应该只有一个可以导致变化的原因。
二、单一职责原则能解决什么问题
回顾我们的 Android 开发经历，很多人都会发现 Activity 类中的代码总会不知不觉地变得很多，这会让读我们代码的人非常痛苦。而造成这种情况的其中一个原因是：Activity
中需要与用户进行大量的交互，用户的操作会改变 Activity 当前显示的界面元素/对应的信息，所以我们总会把 Model、View、点击事件等等……操作全都放到了 Activiy 中，但这样存在一个很严重的问题，无脑地为
Activity 添加代码，势必让 Activity 变得臃肿，结构混乱，职责模糊，特别是之前负责该项目的工程师已经离职，新入职的工程师需要重构该 Activity 时，必将痛不欲生。
三、实例
通过一个小 Demo 以单一职责原则的思想为 Activity 解耦，详情如下：
public class Data {
private String btn1Str = "btn1 Clicked 1";
private String btn2Str = "btn2 Clicked 1";
private String btn3Str = "btn3 Clicked 1";
private String btn4Str = "btn4 Clicked 1";
public String getData(int index){
if(index == 1)
return btn1Str;
else if(index == 2)
return btn2Str;
else if(index == 3)
return btn3Str;
else
return btn4Str;
}
public void setData(int index,String str){
if(index == 1)
btn1Str = str;
else if(index == 2)
btn2Str = str;
else if(index == 3)
btn3Str = str;
else
btn4Str = str;
}
}
import android.app.Activity;
import android.os.Bundle;
import android.view.View;
import android.view.View.OnClickListener;
import android.widget.Button;
public class MainActivity extends Activity implements OnClickListener{
private Button btn1;
private Button btn2;
private Button btn3;
private Button btn4;
private Data data = new Data();
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
btn1 = (Button)findViewById(R.id.button1);
btn2 = (Button)findViewById(R.id.button2);
btn3 = (Button)findViewById(R.id.button3);
btn4 = (Button)findViewById(R.id.button4);
btn1.setOnClickListener(this);
btn2.setOnClickListener(this);
btn3.setOnClickListener(this);
btn4.setOnClickListener(this);
}
public void updateData(){
//各种网络请求操作更新数据
}
@Override
public void onClick(View v) {
switch(v.getId()){
case R.id.button1:
btn1.setText(data.getData(1));
break;
case R.id.button2:
btn2.setText(data.getData(2));
break;
case R.id.button3:
btn3.setText(data.getData(3));
break;
case R.id.button4:
btn4.setText(data.getData(4));
break;
}
}
}
在 Demo 里我们可以看到，所有相关的操作都在 Activity 里进行，要知道，这还只是一个非常简单的页面，可以说完全不存在业务逻辑。换成一个业务逻辑复杂的页面，这还用玩？接下来换一个思路，用 MVP 模式解耦：
public class Presenter {
private Data data;
private IView iView;
public Presenter(IView iView) {
this.iView = iView;
data = new Data();
}
public Data getData(){
return data;
}
public void setData(int index,String str){
//各种网络请求更新数据
data.setData(index, str);
updateView();
}
private void updateView(){
iView.updateView(data);
}
}
public interface IView {
public void updateView(Data data);
}
import android.app.Activity;
import android.os.Bundle;
import android.view.View;
import android.view.View.OnClickListener;
import android.widget.Button;
public class MainActivity extends Activity implements IView,OnClickListener{
private Button btn1;
private Button btn2;
private Button btn3;
private Button btn4;
private Presenter presenter;
private Data data = new Data();
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
btn1 = (Button)findViewById(R.id.button1);
btn2 = (Button)findViewById(R.id.button2);
btn3 = (Button)findViewById(R.id.button3);
btn4 = (Button)findViewById(R.id.button4);
btn1.setOnClickListener(this);
btn2.setOnClickListener(this);
btn3.setOnClickListener(this);
btn4.setOnClickListener(this);
presenter = new Presenter(this);
}
@Override
public void updateView(Data data) {
this.data = data;
}
@Override
public void onClick(View v) {
switch(v.getId()){
case R.id.button1:
btn1.setText(data.getData(1));
break;
case R.id.button2:
btn2.setText(data.getData(2));
break;
case R.id.button3:
btn3.setText(data.getData(3));
break;
case R.id.button4:
btn4.setText(data.getData(4));
break;
}
}
}
进行这样的重构之后，Activity 类发生了什么变化呢？我们先回想下 Android SDK 对 Activity 的定义吧：
An activity is a single, focused thing that the user can do. Almost all activities interact with the user, so the Activity class takes care of creating a window for you in which you can place your UI with {@link #setContentView}. While
activities are often presented to the user as full-screen windows, they can also be used in other ways: as floating windows (via a theme with {@link android.R.attr#windowIsFloating} set) or embedded inside of another activity
(using {@link ActivityGroup}).
简单翻译下：Activity 象征用户能完成的一件事，大部分 Activity 用于和用户进行交互，在其中放置我们的 UI。
也就是说，Google 官方认为 Activity 的职责是：呈现 UI，与用户交互。
那么之前的代码很显然违反了单一职责原则了，因为在 Activity 中不但要进行数据的请求和更新、根据用户的交互/更新的数据去修改
View。那么新代码让 Activity 发生了什么改变呢？第一、数据的请求/更新由 Presenter 处理，不需要经过 Activity 去请求/更新；第二、View 相关的逻辑（如：修改）由 IView 接口提供，Activity
只需要完成具体实现。
四、遵循单一职责原则有什么好处
那么进行这样的重构有什么好处呢？我相信看了示例之后，大家心里多少会有些说不清、道不明的触动，特别是回忆起过去写的一些结构糟糕的代码时触动会更深些。实际上，我个人认为设计模式中的思想和生活中高效组织、完成工作的思想都是一致的，因为所谓设计模式，本身就是前人对写代码的经验总结，其目的就在于：提高效率，便于维护，让代码易读，易拓展等等……回顾生活，我们要想让一个团队/组织/公司/企业高效运作，那么这个群体就得根据实际划分部门
—> 确立部门沟通规范 —> 部门内再次进行团队职责细分（例如 UI 部门分为：视觉设计、交互设计等等……） —> 部门成员明确分工，尽可能让整个群体结构呈现为模块化、低耦合、高内聚、职责区分清晰的结构。
而单一职责原则体现的也是这样的思想，一个类，应该只受其最根本的抽象逻辑影响，类内的具体变化都应该来自于该抽象逻辑，我们说单一职责，我认为其含义不在于一个类做一件事，而在于一个类就是一个抽象群体，抽象群体具有自身的属性和职责，它的职责可能需要它做很多事，但它的职责始终唯一。
进行这样的重构之后我们可以把类内不属于它的逻辑剥离出去，让类遵循它的抽象逻辑，而不需要为其他不属于它的职责增加代码。
关注 Android实战开发
微信扫一扫关注公众号
