设计模式之单一职责原则

相关链接：
0. 设计模式之六大原则总结
1. 设计模式之单一职责原则
2. 设计模式之里式替换原则
3. 设计模式之依赖倒置原则
4. 设计模式之接口隔离原则
5. 设计模式之迪米特法则
6. 设计模式之开闭原则

1.1 定义

通俗的说，即一个类只负责一项职责，不要存在1 个以上导致类发生变更的原因。

1.2 问题由来

类 T 负责两个不同的职责：职责 P1 和职责 P2。当职责 P1 需求发生改变时，我们需要修改类 T，此时，就有可能会导致原本运行正常的职责 P2 功能发生故障。

1.3 解决方案

遵循单一职责原则。对于职责 P1 和职责 P2 分别建立 T1 类和 T2 类，T1 类负责完成职责 P1 功能，T2 类负责完成职责 P2 功能。这样，职责 P1 需求改变时，我们只需要修改 T1 类就可以了，不会使职责 P2 发生故障风险；同理，修改 T2 时，也不会使职责 P1 发生故障风险。

1.4 具体分析

对于单一职责原则，很多人都会不屑一顾。因为它太 easy 了，但凡有过一点工作经验的程序猿，在设计软件时也会自觉的遵守这一重要原则，因为这是常识。毕竟，谁都不希望修改一个功能导致其他的功能发生故障吧。

虽然单一职责原则如此简单，并且被认为是常识，但是即便是经验丰富的程序猿写出的程序，也会有违背这一原则的代码存在。为什么会出现这种现象呢？
因为有职责扩散，所谓职责扩散，就是因为产品改需求了，职责 P 被分化为粒度更细的职责 P1 和 P2。

1.5 举例说明

比如：类 T 只负责一个职责 P，这样的设计是符合单一职责原则的。后来由于需求变更，或者是程序猿的内功修炼提高了，需要将职责 P 细分为颗粒度更细的职责 P1，P2，这时如果要使程序遵循单一职责原则，需要将类 T 也分解为两个类 T1 和 T2，分别负责 P1、P2 两个职责。但是在程序已经写好的情况下，这样做简直太费时间了，尤其是在今天提的需求今天要上线的情况下，mmp 了。所以，通常都会简单的修改类 T，用它来负责两个职责是一个简单、快速的选择，虽然有悖于单一职责原则。（这样做的风险在于职责扩散的不确定性，因为产品经理可能会根据这个职责 P，提出 P1、P2、P3....Pn，所以记住，在职责扩散到我们无法控制的程度之前，立刻对代码进行部分重构，要不就脱坑致富）。

1.5.1 初始案例

刚开始，产品提的需求很简单，因为公司是刚成立，前期用户都是没什么攻击力的食草动物：

// 动物类
class Animal: NSObject {
    // static 也表示类方法，但是包含了 final 的特性，不能被重写
    static func eat(name : String) {
        print(name + "吃草");
    }
}

// 运行代码
Animal.eat(name: "牛")
Animal.eat(name: "马")
Animal.eat(name: "羊")

运行结果：

牛吃草
马吃草
羊吃草

1.5.2 案例修改方案1

第一个版本做完了，程序上线了，用户的范围变大了，我们可以为食肉动物提供服务了，比如老虎就是吃肉的。我们不得不修改我们的代码了，如果遵循单一职责原则，需要将 Animal 类，细分成食草动物类Herbivore 和 食肉动物类Predator，代码如下：

// 食草动物类
class Herbivore: NSObject {
    static func eat(name : String) {
        print(name + "吃草");
    }
}

// 食肉动物类
class Predator: NSObject {
    static func eat(name : String) {
        print(name + "吃肉");
    }
}

// 运行代码
Herbivore.eat(name: "牛")
Herbivore.eat(name: "马")
Herbivore.eat(name: "羊")

Predator.eat(name: "老虎")

运行结果：

牛吃草
马吃草
羊吃草
老虎吃肉

1.5.3 案例修改方案2

之后，我们可以分别对食肉动物和食草动物，采取不同的类就可以了，但是这样修改的话，花销是很大的。而直接修改类 Animal来达成目的，虽然违背了单一职责原则，但是花销却小的多，代码如下：

class Animal: NSObject {
    // static 也表示类方法，但是包含了 final 的特性，不能被重写
    static func eat(name : String) {
        if name == "老虎" || name == "狼"{
            print(name + "吃肉");
        }else{
            print(name + "吃草");
        }
    }
}

可以看到，这种方法简单的多了，而且会有相当多的一部分人使用这种方法，因为快啊。但是却存在着隐患，比如产品又升级了，我们需要对用户更进一步的划分，比如食草动物中，有的动物喜欢吃晒干的草，有的动物喜欢吃新鲜的草，那么我们有需要对eat方法进行修改了，但是这样修改的话会给食肉动物的eat功能带来风险。这种修改方式直接在代码级别上违背了单一职责原则，虽然修改起来最简单，但是隐患是最大的。

1.5.4 案例修改方案3

还有一种修改方式，既然动物eat的行为不一样，那么我们就赋予动物不同的eat行为，然后分别调用，比如：

class Animal: NSObject {
    
    class func eat(name : String) {
        print(name + "吃草");
    }
    
    class func eat2(name : String) {
        print(name + "吃肉");
    }
}

可以看到，这种修改方式没有改动原来的方法，而是在类中新添加了一个方法，这样虽然也违背了单一职责原则，但是在方法级别上却是符合单一职责原则的，因为它并没有改动原来方法的代码。

1.6 总结

这三种方案各有优缺点，在实际编程中，我个人感觉采用 2、3 种方法的会比较多。这里有一个建议：只有逻辑足够简单，才可以在代码级别上违反单一职责原则；只有类中方法数量足够少，才可以在方法级别上违反单一职责原则。

像上面这个例子，它太简单了，只有一个方法，所以，无论是在代码级别上违反单一职责原则，还是在方法级别上违反，都不会造成太大的影响。实际应用中的类都要复杂的多，一旦发生职责扩散而需要修改类时，除非这个类本身非常简单，否则还是遵循单一职责原则的好。

遵循单一职责原则的优点：

• 可以降低类的复杂度，一个类只负责一项职责，其逻辑肯定要比负责多项职责简单的多
• 提高类的可读性，提高系统的可维护性
• 变更引起的风险降低，变更时必然的，如果单一职责原则遵守的好，当修改一个功能时，可以显著降低对其他功能的影响

单一职责原则，不只是面向对象编程思想所特有的，只要是模块化的程序设计，或者是在日常工作中，员工分工安排上，都适用单一职责原则。