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

单一职责原则是最简单的面向对象设计原则,它用于控制类的粒度大小。单一职责原则定义以下:数据库

单一职责原则(Single Responsibility Principle, SRP):一个类只负责一个功能领域中的相应职责,或者能够定义为:就一个类而言,应该只有一个引发它变化的缘由。spa

      单一职责原则告诉咱们:一个类不能太“累”!在软件系统中,一个类(大到模块,小到方法)承担的职责越多,它被复用的可能性就越小,并且一个类承担的职责过多,就至关于将这些职责耦合在一块儿,当其中一个职责变化时,可能会影响其余职责的运做,所以要将这些职责进行分离,将不一样的职责封装在不一样的类中,即将不一样的变化缘由封装在不一样的类中,若是多个职责老是同时发生改变则可将它们封装在同一类中。设计

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

      下面经过一个简单实例来进一步分析单一职责原则:ip

Sunny软件公司开发人员针对某CRM(Customer Relationship  Management,客户关系管理)系统中客户信息图形统计模块提出了如图1所示初始设计方案:ci

图1  初始设计方案结构图开发

在图1中,CustomerDataChart类中的方法说明以下:getConnection()方法用于链接数据库,findCustomers()用于查询全部的客户信息,createChart()用于建立图表,displayChart()用于显示图表。get

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

      在图1中,CustomerDataChart类承担了太多的职责,既包含与数据库相关的方法,又包含与图表生成和显示相关的方法。若是在其余类中也须要链接数据库或者使用findCustomers()方法查询客户信息,则难以实现代码的重用。不管是修改数据库链接方式仍是修改图表显示方式都须要修改该类,它不止一个引发它变化的缘由,违背了单一职责原则。所以须要对该类进行拆分,使其知足单一职责原则,类CustomerDataChart可拆分为以下三个类:io

      (1) DBUtil:负责链接数据库,包含数据库链接方法getConnection();

      (2) CustomerDAO:负责操做数据库中的Customer表,包含对Customer表的增删改查等方法,如findCustomers();

      (3) CustomerDataChart:负责图表的生成和显示,包含方法createChart()和displayChart()。

      使用单一职责原则重构后的结构如图2所示:

图2  重构后的结构图

相关文章
相关标签/搜索