面向对象编程原则(03)——单一职责原则

---

版权声明

• 本文原创作者：谷哥的小弟
• 作者博客地址：http://blog.csdn.net/lfdfhl

---

参考资料

1. 《大话设计模式》 作者：程杰
2. 《Java设计模式》 作者：刘伟
3. 《图解设计模式》 作者：结城浩
4. 《重学Java设计模式》 作者：付政委
5. 《Head First设计模式》作者：埃里克·弗里曼

---

单一职责原则概述

单一职责原则(Single Responsibility Principle, SRP)是最简单的面向对象设计原则；它常用于控制类的粒度大小。

该原则定义如下：

一个对象应该只包含单一的职责，并且该职责被完整地封装在一个类中。

Every object should have a single responsibility,and that responsibility should be entirely encapsulated by the class.

在软件系统中一个类(大到模块，小到方法)承担的职责越多，它被复用的可能性就越小；而且一个类承担的职责过多，相当于将这些职责耦合在一起，当其中一个职责变化时可能会影响其他职责的运作。因此要将这些职责进行分离，将不同的职责封装在不同的类中。即将不同的变化原因封装在不同的类中，如果多个职责总是同时发生改变则可将它们封装在同一类中。

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

单一职责原则案例

在CustomerDataChart类中：

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

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

因此，需要对该类进行拆分使其满足单一职责原则，可将CustomerDataChart类拆分为以下3个类。

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