面向对象设计原则-单一职责原则

单一职责原则(Single Reponsibility Principle，SRP)

一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因

如果一个对象承担了太多的职责，至少存在以下两个缺点

1. 一个职责的变化可能会削弱或者抑制这个类实现其他职责的能力
2. 当客户端需要该对象的某一个职责时，不得不将其它不需要的职责全部包含进来，从而造成冗余代码或代码的浪费

单一职责原则的优点

单一职责的核心就是控制类的粒度大小、将对象解耦、提高其内聚性

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

单一职责原则是实现高内聚、低耦合的指导方针，它是最简单又最难运用的原则，需要设计人员发现类的不同职责并将其分离，再封装到不同的类或模块中，而发现类的多重职责需要设计人员具有较强的分析设计能力和相关实践经验

通过一个案例来进一步了解单一职责原则

某CRM（Customer Relationship Management，客户关系管理）系统中客户信息图形统计模块初始设计方案

在图1中，CustomerDataChart类中的方法说明如下

• getConnection()： 用于连接数据库
• findCustomers()： 用于查询所有的客户信息
• createChart()： 用于创建图表
• displayChart()： 用于显示图表

使用单一职责原则对其进行重构

重构原因：CustomerDataChart类承担了太多的职责，既包含与数据库相关的方法，又包含与图表相关方法。
如果在其他类中也需要连接数据库或者使用findCustomers()方法查询客户信息，则难以实现代码的重用。无论是修改数据库连接方式还是修改图表显示方式都需要修改该类，它不止一个引起它变化的原因，违背了单一职责原则
对CustomerDataChart类进行重构后拆为如下三个类

1. DBUtil： 负责连接数据库，包含数据库连接方法getConnection()
2. CustomerDAO： 负责操作数据库中的Customer表，包含对Customer表的增删改查等方法，如findCustomers()
3. CustomerDataChart： 负责图表的生成和显示，包含方法createChart()和displayChart()

注：单一职责同样也适用于方法。一个方法应该尽可能做好一件事。如果一个方法处理的事情太多，其粒度会变得很粗，不利于重用