设计模式六大原则之----单一职责原则

一、定义

规定一个类只有一个发生变化的原因。通俗理解为：一个类只负责一项职责。

友情提醒：xmind导出的图片有点模糊，请放大查看

二、 问题的由来

2.1 问题

类T负责两个不同的职责，当职责P1改变需求时需要修改T类,这时候就有可能因为修改的逻辑导致职责P2出现故障

2.2 解决方案

遵循单一原则，创建两个类T1和T2，在修改T1的时候不会影响T2，同理，修改T2的时候也不影响T1的逻辑

三、 特点

• 降低类的复杂度，每个类和接口都有清晰明确的定义
• 提高代码可读性
• 提高代码可维护性
• 降低变更引起的风险

四、 重点

• 接口遵循单一职责。
  
  • 例如：ListView中的itemClick和itemLongClick都有不同的接口
• 类的单一职责比较难以实现，尽量做到只有一个原因引起变化
• 方法遵循单一原则
  
  • 一个方法尽可能只做一件事，能分解就分解，分解到原子级别

五、案例

创建一个动物类，告诉系统，这些动物都是呼吸什么的。

5.1 实现需求

功能类：

class Aniaml{
    public void breath(String animal){
        Log.e(TAG,animal+"呼吸空气");
    }
}

调用逻辑：

Aniaml aniaml = new Aniaml();
aniaml.breath("牛");
aniaml.breath("羊");

执行结果：

11-14 19:16:59.752 28316-28316/? E/MainActivity: 牛呼吸空气
11-14 19:16:59.753 28316-28316/? E/MainActivity: 羊呼吸空气

5.2 解决BUG

由于之前实现的时候没有考虑到水生动物，它是呼吸水的，而不是呼吸空气的。

普通代码处理（不遵循单一职责原则）：

class Aniaml{
    public void breath(String animal){
        // 这里是水生动物判断条件，简单表示
        if ("鱼".equals(animal)){
            Log.e(TAG,animal+"呼吸水");
        }else{
            Log.e(TAG,animal+"呼吸空气");
        }
    }
}

添加breath(“鱼”)，执行结果：

11-14 19:20:23.927 30833-30833/com.designpatterndisclipline E/MainActivity: 牛呼吸空气
11-14 19:20:23.927 30833-30833/com.designpatterndisclipline E/MainActivity: 羊呼吸空气
11-14 19:20:23.927 30833-30833/com.designpatterndisclipline E/MainActivity: 鱼呼吸水

这种方式修改的简单，但是会埋下隐患，目前代码逻辑比较少，不会出问题，如果再复杂的话，有可能某天运行后结果会是牛呼吸水，这就比较尴尬了。

5.3 完全遵循单一职责原则解决BUG

完全遵循单一职责原则，则需要把Animal拆分成两个类，一个呼吸水一个呼吸空气

class Animal1{
    public void breath(String animal){
        Log.e(TAG,animal+"呼吸水");
    }
}
class Animal2{
    public void breath(String animal){
        Log.e(TAG,animal+"呼吸空气");
    }
}

客户端调用逻辑：

Animal1 aniam1 = new Animal1();
Animal2 aniam2 = new Animal2();
aniam2.breath("牛");
aniam2.breath("羊");
aniam1.breath("鱼");

运行结果：

11-14 19:26:06.400 2693-2693/com.designpatterndisclipline E/MainActivity: 牛呼吸空气
11-14 19:26:06.400 2693-2693/com.designpatterndisclipline E/MainActivity: 羊呼吸空气
11-14 19:26:06.400 2693-2693/com.designpatterndisclipline E/MainActivity: 鱼呼吸水

这种方案完全遵循单一职责原则，完全解决了BUG，但是在实际情况中，这种情况还是比较少见的，因为一个类不会像例子里那么简单，相当复杂，如果为了一个BUG，把一个类拆分成两个类，工作量是非常大的，也是不可取的。

5.4 方法遵循单一职责原则解决该BUG

在原先的Animal类中添加一个方法来处理水生动物呼吸的逻辑，在调用的时候修改调用方法即可。

class Animal{
    public void breath(String animal){
        Log.e(TAG,animal+"呼吸空气");
    }
    public void breath1(String animal){
        Log.e(TAG,animal+"呼吸水");
    }
}

客户端调用逻辑：

Animal aniaml = new Animal();
aniaml.breath("牛");
aniaml.breath("羊");
aniaml.breath1("鱼");

执行结果：

11-14 19:31:03.231 6189-6189/? E/MainActivity: 牛呼吸空气
11-14 19:31:03.231 6189-6189/? E/MainActivity: 羊呼吸空气
11-14 19:31:03.231 6189-6189/? E/MainActivity: 鱼呼吸水

最后这种解决办法虽然没有完全遵循单一职责原则，但是遵循了方法的单一职责，相较完全的遵循单一职责要优雅得多，所以，在项目构建过程中，并不一定完全按照6大原则进行。