单一责任原则与分离问题的区别

单一责任原则与分离关注有何区别?

单一责任原则(Single Responsibility Principle,简称SRP) – 给每个class级一个改变原因的理由; 和“改变的原因”==“责任”。 例如:发票类没有责任打印本身。

分离问题(自1974年以来)。 关注==系统的function。 照顾每一个问题:对于每一个问题,其他问题都是无关紧要的。 隐藏行为的实现。

从这里 。

分离关注与单一责任原则(SoC vs SRP)

从链接的文章:

分离问题(SoC) – 是将计算机程序分解成function尽可能less的不同function的过程。 一个关心的问题是计划中的任何一个利益或重点。 通常,担心与特征或行为是同义的。 http://en.wikipedia.org/wiki/Separation_of_concerns

单一责任原则(Single Responsibility Principle,简称SRP) – 每一个客体都应该有一个单一的责任,所有的服务都应该和责任完全一致。 在某种程度上,凝聚力被认为是SRP的同义词。 http://en.wikipedia.org/wiki/Single_responsibility_principle

在我看来,单一责任原则是实现问题分离的工具/成语之一。

单一责任指出一个对象负责一个工作单元。

关注点的分离表明,应用程序应该被分解成function尽可能less重叠的模块。

类似的最终结果…稍有不同的应用。

单一责任原则与问题分离真的是一回事。

当然,你可以在学术讨论中陷入困境,试图梳理出两者之间的某种差异,但是为什么呢? 为了所有的意图和目的,他们描述了同样的事情。 最大的问题是人们如此深深地想知道“关心”和“责任”是什么,他们可能错过了SRP和SoC背后的重要思想。

这个想法很简单,就是把你的代码分解成松散耦合的隔离部分。 这允许多个开发人员在不同的部分上工作,而不会相互影响,也允许单个开发人员修改一个孤立的部分而不会破坏另一个部分。

这在模块级应用,例如MVC是促进SRP和SoC的架构模式。 代码库被拆分成独立的模型,视图和控制器。 这样一个视图的修改可以独立于模型完成。 两个不是可怕的交织在一起。

在较低的水平上,这也应该适用于课堂。 不要把几十个方法放在一个类中,而是把代码分成几个。 出于同样的原因。

即使在方法级别,也可以将大的方法分割成更小的方法。

原则上。 SRP是一个原则,而不是一个规则,所以你不需要(阅读:不能/不应该)虔诚地遵循它的极端。 这并不意味着要走得太远,例如每个class只有一个七行的方法。 这只是将代码分解成孤立部分的一般原理。 关键是它会导致更好的代码库和更稳定的软件。

分离关注点(SoC)。 将应用程序划分为不同的function,尽可能less地重叠。 (微软)。

“关注”=“截然不同的特征”=“截然不同的部分”

“关注”在高低两个方面都起作用

单一职责原则规定,每个模块或类别都应该对软件提供的function的单一部分负责,而责任应该完全由类别封装。 所有的服务都应该与这个责任完全一致。 (维基百科定义)

“责任”=“改变的理由”改变什么? “软件提供的function的一部分”= 基本单元

结论

  • 单一责任原则适用于基层单位 – >低层次的工作

  • 分离问题在高层和低层都起作用

  • SRP和SoC共同合作解决问题。 他们是
    在低层完全一样

分离关注是一个过程; 单一责任原则是一种devise/build筑理念。 他们并不完全不相交,但他们有不同的目的。

类似但是:SoC涉及到的关注点是:把一个复杂的问题分解成几个问题,SRP就是有一个责任。

SRP和SOC在不同的抽象层次上工作。 目的是在这两种情况下减less耦合和加强凝聚力。 虽然SRP更多地在对象级别上工作,但是SOC也可以在function级别上实现。 一个函数可以由一个对象实现,也可以由多个对象实现。 因此,两种原则的耦合和凝聚力可能不同。

我试图比较分离关注点(SoC)和单一责任原则(SRP)。

差异

  • SRP处于课堂级别,但SoC在每个计算机程序,抽象…或有时是架构级别。

  • SRP是关于你的领域分成只有一个责任(改变原因之一)的凝聚力类的质量(怎么不是)。 另一方面,SoC是将上下文分离为不同部分的devise原则,因此每个部分都有一个单独的关注点(不知道怎么做),因为有很多工具(例如类,函数,模块,包等等)。 ..)达到这个目标不同的水平。

  • SRP的概念是基于凝聚力(高凝聚力),而SoC则接近于分子,分而治之(D&C),…在每个抽象层次上。

  • SoC是应对复杂性的一个很好的devise原则,比如抽象,而为了达到单个负责任的类,你可以使用SoC原则作为一个很好的解决scheme。 作为一个知道一个class级有多个责任的方法是,如果你能从这个class级中提取另一个责任(关注)。

相似

  • 应用这些原则之后,您的上下文变得更加可重用,可维护,健壮,可读,…。
Interesting Posts