设计原则-SRP单一职责原则

1.定义

 任何一个类或者模块都应该只对某一个或一类行为者负责。

也就是说不要设计大而全的类，要设计粒度小、功能单一的类。换个角度来讲就是，一个类包含了两个或者两个以上业务不相干的功能，那我们就说它职责不够单一，应该将它拆分成多个功能更加单一、粒度更细的类。

2.分析

为什么要遵循单一职责原则？

1）减少脆弱

当一个类有多个理由需要修改时，它变得脆弱，在一个地方的修改会导致其他地方不可预期的后果。

2）更松耦合

更多职责责任导致更高的耦合，高度耦合导致高度依赖，意味着难以维护。

3）代码改变

对于单一职责模块重构更容易。

4）维护性

维护一个单一职责的类比维护一个铁板一块的类更容易。

5）易于测试

测试单一目标的类只需要很少的测试类。

6）易于调试

在一个单一职责类找到问题是一件更容易的事情。

 

如何判断违反单一职责原则？

1）类有太多依赖

2）方法有太多参数

3）类或者方法太长

如果方法太长，意味着内容太多，职责过多。

4）名称不能用一个词来描述

如果你需要描述你的类 方法或包，比如使用"xxx和xxx"这种语句，意味着可能破坏了SRP。

 

3.案例

一个类的三个函数分别对应的是三类不同的行为者。使三类行为者的行为耦合在了一起，这可能会导致CFO团队的命令影响到COO团队所依赖的功能。

假设一种情况，calculatePay()方法和reportHours()方法使用相同的逻辑来计算正常工作时长，程序员为了避免重复编码，将该算法单独实现为一个名为regularHours的方法。当CFO团队修改了regularHours方法，但不知道reportHours方法也调用了regularHours方法，同时也影响了COO团队的功能。

 

 

 

 改正的方法是，变成三个类，每个类只包含与之相关的函数代码，互相不可见，这样就不存在互相依赖的情况了。三个类共同使用一个不包括函数的、简单的数据类。

 

 

 

缺点是，使用者需要在程序里处理三个类。使用Facade设计模式来统一对外公布。