六大设计原则之单一职责原则

该原则由罗伯特·C.马丁（Robert C.Martin）在《敏捷软件开发：原则、模式与实践》一书中提出。

定义：规定一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分。

假设我们有一个类负责两个职责，一旦发生需求变更，修改其中一个职责的逻辑代码，有可能导致另一个职责的功能发生故障。这样一来，这个类就存在两个导致类变更的原因

解决办法：
将两个职责用两个类来实现，进行解耦。后期需求变更维护互不影响。

单一职责原则适用的范围有接口、方法、类。

该原则提出对象不应该承担太多职责，如果一个对象承担了太多的职责，至少存在以下两个缺点：
一个职责的变化可能会削弱或者抑制这个类实现其他职责的能力；
当客户端需要该对象的某一个职责时，不得不将其他不需要的职责全都包含进来，从而造成冗余代码或代码的浪费。

遵守单一职责原则的好处：
降低类的复杂度。一个类只负责一项职责，其逻辑肯定要比负责多项职责简单得多。
提高类的可维护性和可读写性
提高系统的可维护性，可读性提高，自然更容易维护
降低变更的风险，变当修改一个功能时，可以显著降低对其他功能的影响。

软件开发中随着需求的不断增加，可能会给原来的类添加一些本来不属于它的一些职责，从而违反了单一职责原则。如果我们发现当前类的职责不仅仅有一个，就应该将本来不属于该类真正的职责分离出去。

一个类只有一个职责，如果职责过多，代码就会臃肿，可读性更差，也更难以维护。

如何遵守单一职责原则：
举例，我们假设一个游戏里面分三类玩家：游客，普通玩家，vip付费玩家。各自完成相应任务有不同的加成：
违背原则的方案：

public class MainLineTaskService {
    //得到加成比例
    public double additionRatio(String playerType){
        double rate = 1.0;
        if("vip".equals(playerType)){
            rate =  3.0;
        }else if("普通玩家".equals(playerType)){
            rate =  2.0;
        }else if("游客".equals(playerType)){
            rate =  1.0;
        }
        return rate;
    }
}

如上，实现业务功能逻辑的方式非常简单，暂时也不会出什么问题。但是这一个类里包含着多个不同的行为，也就是多种玩家职责具有不同行为。如果在这样的类上继续扩展功能或添加逻辑，就会显得非常臃肿。
对于简单的或者几乎不需要迭代的功能，这种实现也未尝不可。但如果面对频繁迭代的业务需求，这样的代码结构就很难支撑系统迭代，每一次需求的实现都可能会影响其他逻辑，给整个接口服务带来不可控的风险。

单一职责原则改善代码:
定义接口：

public interface IMainLineTaskService {
    //获取加成比例
    double additionRatio();
    
    //任务加速
    void speedUp();
}

游客实现类：

public class TouristsMainTaskService implements IMainLineTaskService{
    @Override
    public double additionRatio() {
        return 1.0;
    }

    @Override
    public void speedUp() {
        //游客任务加速实现
    }
}

普通玩家实现类：

public class NormalMainTaskService implements IMainLineTaskService {
    @Override
    public double additionRatio() {
        return 2.0;
    }

    @Override
    public void speedUp() {
        //普通玩家任务加速实现
    }
}

VIP玩家实现类：

public class VipMainTaskService implements IMainLineTaskService{
    @Override
    public double additionRatio() {
        return 3.0;
    }

    @Override
    public void speedUp() {
        //vip玩家任务加速实现
    }
}

每种玩家对应的服务职责都有对应的类实现，不会互相干扰。当某一类玩家需要添加新的运营规则时，操作起来也可以非常方便

单一职责原则是最简单但又最难运用的原则，需要设计人员发现类的不同职责并将其分离，再封装到不同的类或模块中。而发现类的多重职责需要设计人员具有较强的分析设计能力和相关重构经验

UML图：

SRP.jpg

单一职责，追求的是简单明确的设计，强调的是分工明确，职责简单。这种设计，不局限于类的设计，可以扩展到任何一个程序逻辑单元的设计，如函数的设计，模块的设计，工程的设计，项目的设计，集群的设计等。

类的职责越单一，越容易重用