六大设计原则之单一职责原则（SRG）

在做代码练习或者开发的过程中，我们会发现自己写的类越来越大，该类的功能也越来越多。有一些开发者包括之前的我看到自己写的类够大，功能够多是往往会充满自豪感。但是当某个功能需要做一个小改动时，就会发现整个程序出现了各种大大小小的问题。

为什么知识对这个类的一个功能做了小小的修改就会引起这么大的问题？因为我们违反了单一职责原则。将多种功能集成在一个类中，就等于把这些功能耦合了起来，一个功能的变化可能会削弱或者抑制这个类完成其他职责的能力。而如果想要避免这种现象的发生，就要尽可能的遵守单一职责原则。此原则的核心就是解耦和增强内聚性。

1. 解说定义

定义：不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。

在一个类中，可以导致类变更的因素最多只能有一个。何为类变更呢？当你要改变该类中某些代码时，该类的某些用途或特性会随着改变。
但是无论你怎么改，这个类只有最多一个用途或特性改变了，而不会再有其他的改变。只有这样一个类的改变对其他使用到该类的模块影响才会达到最低。也只有一个类只实现一个功能时才能做到到这种最小的改变。

2. 问题由来

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

3. 解决办法

遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会使职责P1发生故障风险。

4.职责扩散

很多程序员都清楚自己编程时要遵循单一职责原则，但总是在不经意间违反了这个原则。因为某种原因，某一职责需要分化为粒度更细的多个职责了，这就是职责扩散。

5.例子

public interface ICar { //品牌void setPinPai(String pinpai);void getPinPai();//颜色void setColor(String color);void getColor();//启动boolean Start(boolean start);//停车boolean Stop(boolean stop);
}

从上面例子中，我们不知道这个接口的具体职责是什么，有点模糊不清。车子的品牌和颜色是车子的属性，而启动和停车是车子的行为，将车子的属性和行为耦合到一个接口中，给人一种结构职责不清的感觉，对后期的维护带来一定的麻烦。

为了解决这个问题，应当使用单一职责原则，将车子接口中的业务对象（属性）和业务逻辑（行为）解耦，分成两个接口，如下：

/*** BO：Bussiness Object，业务对象  * 负责车子的属性  * @author 叶汉伟*/
public interface ICarBO {//品牌void setPinPai(String pinpai);void getPinPai();//颜色void setColor(String color);void getColor();
}

/**  * BL:Business Logic,业务逻辑  * 负责车子的行为  * @author 叶汉伟*/
public interface ICarBL {//启动boolean Start(boolean start);//停车boolean St#p%Cspan class="hljs-params">(boolean stop);
}

这样就实现了接口的单一职责原则。他们各自有一个实现类CarBO、CarBL。当需要修改车子属性的时候只需要对CarBO这个接口来修改，只会影响到CarBO这个类，不会影响其他类。

6. 优点

可以使得类的逻辑变得简单，功能清晰。每个类只负责一个职责，那么这个类的功能是非常清晰的，相比于有多个职责的类，单一职责的类的逻辑会更简单。
程序的可读性和可维护性相对较强。
降低变更引起的风险，对系统扩展性和维护性很有帮助。

但是，单一职责原则有时候会给我们带来一些麻烦。如果职责太多的话，每个职责一个类，会造成类的数量过多，反而降低了代码的可读性和程序的可维护性。所以使用这个职责的时候还要具体情况具体分析。建议就是接口一定要采用单一职责原则，实现类的设计上尽可能做到单一职责原则，最好是一个原因引起一个类的变化。