关注点分离与单一职责

关注点分离separation of concerns,SOC)是对只与“特定概念、目标”(关注点)相关联的软件组成部分进行“标识、封装和操纵”的能力,即标识、封装和操纵关注点的能力。是处理复杂性的一个原则。由于关注点混杂在一起会导致复杂性大大增加,所以能够把不同的关注点分离开来,分别处理就是处理复杂性的一个原则,一种方法。

http://blog.csdn.net/lovelion/article/details/7536542

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


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

 

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

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

遵守单一职责原则,将不同的职责封装到不同的类或模块中。

单一职责原则:此原则的核心就是解耦和增强内聚性

时间: 2025-01-02 16:11:46

关注点分离与单一职责的相关文章

(1)Single Responsibility Principle【单一职责原则】

单一职责原则 SRP:Single responsibility principle [概述]单一职责原则又称单一功能原则,面向对象五个基本原则(SOLID)之一.它规定一个类应该只有一个发生变化的原因.该原则由罗伯特·C·马丁(Robert C. Martin)于<敏捷软件开发:原则.模式和实践>一书中给出的.马丁表示此原则是基于汤姆·狄马克(Tom DeMarco)和Meilir Page-Jones的著作中的内聚性原则发展出的. 所谓职责是指类变化的原因.如果一个类有多于一个的动机被改变

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

单一职责原则(Single Responsibility Principle SRP) There should never be more than one reason for a class to change. 什么意思呢? 所谓单一职责原则就是一个类只负责一个职责,只有一个引起变化的原因. 如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化会削弱或抑制这个类完成其他职责的能力,这个耦合会脆弱的设计. 软件设计真正要做的许多内容,就是发现职责并把这些职责相互分离:如果能

【设计模式之禅】第1章 单一职责原则

1.1 我是"牛"类,我可以担任多职吗 SRP 单一职责原则的英文名称是Single Responsibility Principle,简称是SRP. RBAC模型(Role-Based Access Control)基于角色的访问控制        通过分配和取消角色来完成用户权限的授予和取消,使动作主体(用户)与资源的行为(权限)分离 单一职责原则的定义是:应该有且仅有一个原因引起类的变更. 1.2 绝杀技,打破你的传统思维 SRP的原话解释是:        There shou

敏捷软件开发 – SRP 单一职责原则

SRP:单一职责原则  一个类应该只有一个发生变化的原因. 为何把两个职责分离到单独的类中很重要呢?因为每一个职责都有变化的一个轴线.当需求变化时,该变化会反映为类的职责的变化.如果一个类承担了多于一个的职责,那么引起它变化的原因就会有多个. 如果一个类承担的职责过多,就等于把这些职责耦合在了一起.一个职责发生变化可能会削弱或抑制这个类完成其他职责的能力.这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏. 有两个不同的应用程序使用Rectangle类.一个应用程序是有关计算几何

C#设计模式系列:单一职责原则(Single Responsibility Principle)

1.单一职责原则的核心思想 一个类应该有且只有一个变化的原因. 2.为什么要引入单一职责原则 单一职责原则将不同的职责分离到单独的类,每一个职责都是一个变化的中心.当需求变化时,这个变化将通过更改职责相关的类来体现.如果一个类拥有多于一个的职责,则这些职责就耦合到在了一起,那么就会有多于一个原因来导致这个类的变化.对于某一职责的更改可能会损害类满足其他耦合职责的能力.这样职责的耦合会导致设计的脆弱,以至于当职责发生更改时产生无法预期的破坏. 3.单一职责原则的优点 1>.可以降低类的复杂度,一个

单一职责原则

什么是单一职责原则 什么是单一职责原则? 单一职责原则的英文名称是Single Responsibility Principle,简称SRP.SRP的原话解释是:There should never be more than one reason for a class to change. 也就是说一个类,只有一个引起它变化的原因.应该只有一个职责.每一个职责都是变化的一个轴线,如果一个类有一个以上的职责,这些职责就耦合在了一起. 这会导致脆弱的设计.当一个职责发生变化时,可能会影响其它的职责

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

单一职责原则 定义: 不要存在多于一个导致类变更的原因.通俗的说,即一个类只负责一项职责. 问题由来:类T负责两个不同的职责:职责P1,职责P2.当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障. 解决方案: 遵循单一职责原则.分别建立两个类T1.T2,使T1完成职责P1功能,T2完成职责P2功能.这样,当修改类T1时,不会使职责P2发生故障风险:同理,当修改T2时,也不会使职责P1发生故障风险. 单一职责原则是最简单的面向对象设计原则,它用于控制类的粒

设计模式——单一职责原则

职责过多坏处: 如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力. 这种耦合会导致脆弱的设计,当变化发生是,设计会遭受到意想不到的破坏. 单一职责: 软件设计真正要做的许多内容,就是发现职责并把那些职责相互分离. 其实要去判断是否应该分离出类来,也不难,拿就是如果你能够想到多于一个的动机去改变一个类,那么这个类就具有多于一个的职责,就应该考虑类的职责的分离. 总结: 在类的职责分离上多思考,做到单一职责,这样你的代码才是真正的易维护,

单一职责原因

单一职责原则,就一个类而言,应该仅有一个引起它变化的原因. 现在比如说要写一个俄罗斯方块,怎么能实现功能的代码复用呢? 不管怎么样游戏中的有些东西是始终没有变化的,比如说下落.旋转.碰撞判断.移动.堆积这些游戏的逻辑是没有变化的.这些都是和游戏有关的逻辑,和界面如何没有什么关系. 如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力.这种耦合会导致脆弱的设计,设计会遭受到意向不到的破坏. 软件设计真正要做的许多的内容就是发现职责,并把那些