设计模式学习--面向对象的5条设计原则之单一职责原则--SRP

 

一、SRP简介(SRP--Single-Responsibility Principle):

就一个类而言,应该只专注于做一件事和仅有一个引起它变化的原因。

 

所谓职责,我们可以理解他为功能,就是设计的这个类功能应该只有一个,而不是两个或更多。也可以理解为引用变化的原因,当你发现有两个变化会要求我们修改这个类,那么你就要考虑撤分这个类了。因为职责是变化的一个轴线,当需求变化时,该变化会反映类的职责的变化。

“就像一个人身兼数职,而这些事情相互关联不大,,甚至有冲突,那他就无法很好的解决这些职责,应该分到不同的人身上去做才对。”

 

二、举例说明:

违反SRP原则代码: 
modem接口明显具有两个职责:连接管理和数据通讯;

interface Modem
{
    public void dial(string pno);
    public void hangup();
    public void send(char c);
    public void recv();
}

 

如果应用程序变化影响连接函数,那么就需要重构:

interface DataChannel
{
    public void send(char c);
    public void recv();
}
interface Connection
{
    public void dial(string pno);
    public void hangup();
}

 

三、SRP优点:

消除耦合,减小因需求变化引起代码僵化性臭味

 

四、使用SRP注意点:

1、一个合理的类,应该仅有一个引起它变化的原因,即单一职责; 
2、在没有变化征兆的情况下应用SRP或其他原则是不明智的; 
3、在需求实际发生变化时就应该应用SRP等原则来重构代码; 
4、使用测试驱动开发会迫使我们在设计出现臭味之前分离不合理代码; 
5、如果测试不能迫使职责分离,僵化性和脆弱性的臭味会变得很强烈,那就应该用Facade或Proxy模式对代码重构;

时间: 2024-08-01 06:25:18

设计模式学习--面向对象的5条设计原则之单一职责原则--SRP的相关文章

设计模式学习--面向对象的5条设计原则(转)

这几天重新看了一遍<大话设计模式>,发现果然有不同的感悟,而且自己也上网找了<敏捷软件开发-原则.模式与实践>一书来看,那本书的序言中有一段话我觉得很有道理:"美的东西比丑的东西创建起来更廉价,也更快捷."设计一个软件不关要追求代码的优雅问题,更关乎生产成本等.技术大师们在对软件架构的研究中经历了很长时间的摸索,从面向过程到面向对象,从设计原则到设计模式,总结了许多设计上的经典法则,而我们就只是站在巨人的肩膀上眺望远方而已. 从<大话设计模式>中,大

设计模式学习--面向对象的5条设计原则之开放封闭原则--OCP

一.OCP简介(OCP--Open-Closed Principle):Software entities(classes,modules,functions,etc.) should be open for extension, but closed for modification.软件实体应当对扩展开放,对修改关闭,即软件实体应当在不修改(在.Net当中可能通过代理模式来达到这个目的)的前提下扩展.Open for extension:当新需求出现的时候,可以通过扩展现有模型达到目的. C

设计模式学习--面向对象的5条设计原则之接口隔离原则--ISP

一.ISP简介(ISP--Interface Segregation Principle): 使用多个专门的接口比使用单一的总接口要好.一个类对另外一个类的依赖性应当是建立在最小的接口上的.一个接口代表一个角色,不应当将不同的角色都交给一个接口.没有关系的接口合并在一起,形成一个臃肿的大接口,这是对角色和接口的污染.   "不应该强迫客户依赖于它们不用的方法.接口属于客户,不属于它所在的类层次结构."这个说得很明白了,再通俗点说,不要强迫客户使用它们不用的方法,如果强迫用户使用它们不使

【转载】设计模式六大原则(1):单一职责原则

定义:不要存在多于一个导致类变更的原因.通俗的说,即一个类只负责一项职责. 问题由来:类T负责两个不同的职责:职责P1,职责P2.当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障. 解决方案:遵循单一职责原则.分别建立两个类T1.T2,使T1完成职责P1功能,T2完成职责P2功能.这样,当修改类T1时,不会使职责P2发生故障风险:同理,当修改T2时,也不会使职责P1发生故障风险.          说到单一职责原则,很多人都会不屑一顾.因为它太简单了.稍

设计模式六大原则(1):单一职责原则

定义:不要存在多于一个导致类变更的原因.通俗的说,即一个类只负责一项职责. 问题由来:类T负责两个不同的职责:职责P1,职责P2.当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障. 解决方案:遵循单一职责原则.分别建立两个类T1.T2,使T1完成职责P1功能,T2完成职责P2功能.这样,当修改类T1时,不会使职责P2发生故障风险:同理,当修改T2时,也不会使职责P1发生故障风险.          说到单一职责原则,很多人都会不屑一顾.因为它太简单了.稍

设计模式六大原则 单一职责原则

设计模式六大原则(1):单一职责原则 定义:不要存在多于一个导致类变更的原因.通俗的说,即一个类只负责一项职责,一个人只负责做一件事. ( 一个类,只有一个引起它变化的原因.应该只有一个职责.每一个职责都是变化的一个轴线,如果一个类有一个以上的职责,这些职责就耦合在了一起.这会导致脆弱的设计.当一个职责发生变化时,可能会影响其它的职责.另外,多个职责耦合在一起,会影响复用性.例如:要实现逻辑和界面的分离 ) 问题由来:类T负责两个不同的职责:职责P1,职责P2.当由于职责P1需求发生改变而需要修

设计模式之禅之六大设计原则-单一职责原则

单一职责原则--->类从属性维度的划分:名词属性,动作属性.例如.用户类(User),用户行为类.(UserService)--->类和接口的设计原则要追求的目标是:有且仅有一个原因能引起它的变化.也就是一个接口或类只有一个职责,它就负责同一类的事情,如果所负责的业务超过两类或两类以上,则考虑拆分成不同的接口.   单一职责原则的好处--->类的复杂性降低,实现什么指责都清晰明确的定义--->可读性提高,因为复杂性降低,因此刻度性提高.--->可维护性提高,因为可读性提高,因

《Android 源码设计模式解析与实战》——第1章,第1.1节优化代码的第一步——单一职责原则

第1章 走向灵活软件之路--面向对象的六大原则Android 源码设计模式解析与实战 1.1 优化代码的第一步--单一职责原则单一职责原则的英文名称是Single Responsibility Principle,缩写是SRP.SRP的定义是:就一个类而言,应该仅有一个引起它变化的原因.简单来说,一个类中应该是一组相关性很高的函数.数据的封装.就像老师在<设计模式之禅>中说的:"这是一个备受争议却又及其重要的原则.只要你想和别人争执.怄气或者是吵架,这个原则是屡试不爽的".

简单讲解Java设计模式编程中的单一职责原则_java

单一职责原则:一个类,只有一个引起它变化的原因. 为什么需要单一职责原则? 如果一个类有多个原因要去修改它,那么修改一个功能时,可能会让其他功能产生Bug,所以一个类最好只有一个职责.但实际应用中还是比较难实现的,我们只能是尽量符合这个原则. 有时候,开发人员设计接口的时候会有些问题,比如用户的属性和用户的行为被放在一个接口中声明.这就造成了业务对象和业务逻辑被放在了一起,这样就造成了这个接口有两种职责,接口职责不明确,按照SRP的定义就违背了接口的单一职责原则了. 下面是个例子: packag