软件设计原则----单一职责原则(SRP)http://blog.csdn.net/beyo
发布时间:2020-12-13 19:43:54 所属栏目:百科 来源:网络整理
导读:软件设计原则----单一职责原则(SRP) 陈述: 就一个类而言,应该只有一个导致其变化的原因 分析: 一个职责就是一个变化的轴线。 一个类如果承担的职责过多,就等于将这些职责耦合在一起。一个职责的变化可能会虚弱或者抑止这个类完成其它职责的能力。 多职
软件设计原则----单一职责原则(SRP)
陈述:
就一个类而言,应该只有一个导致其变化的原因 分析:一个职责就是一个变化的轴线。 一个类如果承担的职责过多,就等于将这些职责耦合在一起。一个职责的变化可能会虚弱或者抑止这个类完成其它职责的能力。 多职责将导致脆弱性的臭味。 示例1: Rectangle类具有两个职责: Rectangle类违反了SRP,具有两个职能——计算面积和绘制矩形 修改后的设计如下: 示例2:
Modem类(可能)有两个职责:
--什么是职责?
职责是“变化的原因”。 --上面的例子可能存在两种变化的方式:
修改后的设计如下:
有一点需要注意:在ModemImplementation中实际还是集合了两个职责。这是我们不希望的,但是有时候却是必须的。
但是我们注意到,对于应用的其它部分,通过接口的分离我们已经实现了职责的分离。 ModemImplementation已经不被其它任何程序所依赖。除了main以外,其他所有程序都不需要知道这个函数的存在。
质疑:
Q:ModemImplementation有两个原因引起变化?应采用如下类图。 A:我们面向接口编程,对外公布的是接口而非实现类。如果真要实现类的单一职责,就必须使用组合模式,会引起类间耦合过重、类的数量增加等问题,人为增加设计的复杂性。
单一职责原则的好处:
常见错误提醒:
Employee类包含了业务规则和对持久化的控制。
业务规则经常变化,而持久化方法却一般不变,而且变化原因也完全不同。将这两个职责耦合在一起,将导致每次因为业务规则变化调整Employee类时,所有持久化部分的代码也要跟着变化
小结:
(编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |
推荐文章
站长推荐
- ios – 授权标头在fetch中不起作用 – React Nat
- cocos2d-x 2.x 中KeyboardMove在iOS8下异常 编辑
- ruby-on-rails – OAuth提供商服务和Rails 3
- ruby-on-rails – Rails 4 – 设计:在注册时获取
- c# – Google ClientLogin授权和Google音乐
- jira 6.1.3打开上传屏幕截屏界面后跳转到oracle页
- oracle表空间表分区详解及oracle表分区查询使用方
- ruby-on-rails:通过路径和link_to传递参数
- c# – 类库项目的资源
- flash跨域策略文件crossdomain.xml配置详解
热点阅读