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

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

单一责任原则（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级中提取另一个责任（关注）。

相似

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