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

标签: 数据库数据库相关crm图形
16933人阅读 评论(22) 收藏 举报
分类:

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

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

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

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

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

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

初始设计方案结构图

在图1中,CustomerDataChart类中的方法说明如下:getConnection()方法用于连接数据库,findCustomers()用于查询所有的客户信息,createChart()用于创建图表,displayChart()用于显示图表。

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

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

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

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

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

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

重构后的结构图

【作者:刘伟  http://blog.csdn.net/lovelion

41
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:2670310次
    • 积分:29885
    • 等级:
    • 排名:第170名
    • 原创:218篇
    • 转载:28篇
    • 译文:3篇
    • 评论:2183条
    个人简介
    刘伟(Sunny),中南大学计算机应用技术博士,国家认证系统分析师(2005年),国家认证系统架构设计师(2009年,全国第四名),高级程序员,数据库系统工程师,MCSE,MCDBA,CASI专业顾问与企业内训讲师。具有十多年软件开发、项目管理及教育培训经验,曾在NIIT(印度国家信息技术学院)担任高级讲师,主持和参与30多个软件项目的开发工作,并给国内多家公司提供软件开发、软件设计等培训服务,现主要致力于软件工程、数据挖掘等领域的教学、推广和研究工作。技术专长:软件架构、设计模式、UML、OOAD、数据挖掘等。已出版设计模式书籍四本:《设计模式》(清华大学出版社,2011年)、《设计模式实训教程》(清华大学出版社,2012年)、《设计模式的艺术——软件开发人员内功修炼之道》(清华大学出版社,2013年)、《C#设计模式》(清华大学出版社,2013年)。架构师之家www.chinasa.info站长。
    E-mail:
    weiliu_china@126.com
    微博地址:
    http://weibo.com/csusunny
    博客专栏