单一责任原则与关注点分离的区别

Question

单一责任原则与关注点分离有什么区别？

Answer 1

  

单一责任原则（SRP） -   给每个班级一个理由   更改;和“改变的理由”==   “责任”。例如：发票   班级没有责任   打印自己。

     

关注点分离（自1974年以来）。   关注==系统的特点。以   关心每一个问题：每个问题   一个问题，其他问题是   无关。隐藏实施   行为。

来自here。

Answer 2

Separation of Concern vs Single Responsibility Principle ( SoC vs SRP )

来自链接文章：

关注点分离（SoC） - 是将计算机程序分解为尽可能少地在功能上重叠的不同功能的过程。关注点是程序中的任何兴趣或焦点。通常，顾虑与特征或行为是同义词。 http://en.wikipedia.org/wiki/Separation_of_concerns

单一责任原则（SRP） - 每个对象都应该承担一项责任，并且其所有服务应该与该职责严格一致。在某种程度上，Cohesion被认为是SRP的同义词。 http://en.wikipedia.org/wiki/Single_responsibility_principle

Answer 3

单一责任声明对象负责单个工作单元。

关注点分离表明，应用程序应分成功能性尽可能少的模块。

类似的最终结果......应用略有不同。

Answer 4

在我看来，单一责任原则是实现关注点分离的工具/习语之一。

Answer 5

单一责任原则和关注点分离实际上是一回事。

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

这个想法只是将你的代码库分成松散耦合的孤立部分。这允许多个开发人员在不影响彼此的情况下处理不同的部分，它还允许单个开发人员修改一个孤立的部分而不会破坏另一个部分。

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

在较低级别，这也应该应用于类。而不是将几十个方法放在一个类中，而是将代码分成几个。出于同样的原因。

即使在方法级别，也可以将大型方法拆分为更小的方法。

原则上。 SRP是一个原则，而不是一个规则，所以你不必（读：不能/不应该）将它虔诚地追随到极致。这并不意味着走得太远，例如每个类只有一个七行方法。它只是意味着将代码拆分为孤立部分的一般原则。关键是它会带来更好的代码库和更稳定的软件。

Answer 6

关注点分离（SoC）。将应用程序划分为不同的功能，尽可能减少功能重叠。 （微软）。

“Concern”=“distinct feature”=“distinct section”

“关注”适用于高级和低级

单一责任原则指出每个模块或类应对软件提供的单个功能部分负责，并且该责任应完全由类封装。其所有服务应与该责任严格一致。 （维基百科定义）

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

<强>结论

• 单一责任原则适用于基本单位 - ＆gt;工作水平低

• 关注点分离在高层和低层都有效

• SRP和SoC一起工作以分离关注点。他们是 在低级别完全相同

Answer 7

分离关注是一个过程;单一责任原则是一种设计/架构理念。它们并非完全不相交，但它们有不同的用途。

Answer 8

类似但是：SoC与担忧有关：将复杂问题分解为几个问题，SRP只有一个责任。

Answer 9

SRP和SOC在不同的抽象层次上工作。目的是在两种情况下减少耦合并增强内聚力。虽然SRP在对象级别上工作得更多，但SOC也可以在功能级别的实现上工作。函数可以由一个对象实现，也可以由多个对象实现。因此，两种原理的耦合和内聚可能不同。

Answer 10

我试图在关注点分离（SoC）和单一责任原则（SRP）之间进行比较。

的差异

• SRP属于类级别，但SoC位于每个计算机程序，抽象......或有时是架构级别。

• SRP是关于（如何不是什么）将您的域划分为具有一个责任的一个有凝聚力的类（改变的一个原因）的质量。另一方面，SoC是一个将上下文分成不同部分的设计原则，因此每个部分都解决了一个单独的问题（不是如何），因为有很多工具（例如类，函数，模块，包，等等）。 ..）达到这个目标的不同层次。

• SRP的概念基于内聚力（高内聚力），而SoC接近于分子，分而治之（D＆amp; C），......在每个抽象层次中。

  < / LI>

• SoC是一个很好的设计原则来应对复杂性，例如抽象，而要达到单个负责的类，你可以使用SoC原理作为一个很好的解决方案。因为，如果你能从这个班级中提取另一个责任（关注），那么了解一个班级有多个责任的方法。

相似性

• 在应用这些原则之后，您的上下文变得更具可重用性，可维护性，健壮性，可读性......

Answer 11

由于先前的答案均未引用创建Single Responsibility Principle的罗伯特·马丁（Robert Martin），所以我认为这里需要一个更具权威性的答案。

马丁对SRP的灵感来自戴维·帕纳斯（David Parnas），埃兹格·迪克斯特拉（Edsger Dijkstra，他们创造了 Separation of Concerns ），以及拉里·康斯坦丁（Larry Constantine），他们创造了 Coupling 和< em> Cohesion ）。马丁将他们的想法整合到了SRP中。

  

“单一责任原则”的另一种措辞是：

     

    

将由于相同原因而发生变化的事物聚集在一起。分开那些因不同原因而改变的事物。

  

     

考虑到这一点，您将意识到这只是定义内聚和耦合的另一种方式。我们希望增加由于相同原因而改变的事物之间的凝聚力，并且我们希望减少因不同原因而改变的事物之间的耦合。

     

但是，当您考虑这一原则时，请记住，改变的原因是人。请求更改的是人。而且，您不想通过将许多不同人出于不同原因而关心的代码混合在一起来混淆这些人或您自己。

对于最初的问题，SRP和SoC之间的次要区别是Martin改进了“关注”一词来表示“人”。

Answer 12

答案：

关注点分离（SoC）是一个更通用的术语-它可以在系统级别或较低级别（例如类（甚至是类中的方法））中应用

单一职责原则（SRP）用于在较低级别（例如，在班上

---

要考虑的问题：

1. 在底层，SoC和SRP是同义词。因此，您可以说SRP是一个多余的术语-或者说SoC应该仅用于讨论系统级别

2. 给出（1），术语SoC有点模棱两可。您需要了解相关讨论是关于高级SoC还是较低级别的SoC

3. 要记住SRP仅是较低级别的术语，请考虑一下：在日常语言中，“责任”通常是可以与特定代码绑定的明确定义的事物，而“关注点”是通常有点含糊，可能包含许多相关内容，这也许就是为什么SoC比SRP更自然地适合讨论系统级别的原因

在某种意义上，

4. SoC比SRP要求更严格，因为它适用于系统级别，并且要在系统级别真正实现，还必须在开发过程中使用。系统组件。也就是说，较高级别的SoC意味着较低级别的SoC / SRP不错-但是事实并非如此，也就是说，较低级别的SoC / SRP并不意味着下一个更高级别的SoC或任何东西。包含系统。有关在方法级别实现但在类级别违反的SoC / SRP的示例，请查看此Artur Trosin's blog post。

Answer 13

关注点分离

关注点分离（SOC）原则规定，代码工件应允许人们将注意力集中在某个方面。代码工件可以是任何东西，从特定的功能到类，整个包，甚至整个应用程序都可以。 SOC原理可以应用于一个应用程序中的每个体系结构级别。应用SOC的体系结构示例是分层体系结构。

单一责任原则

单一责任原则（SRP）规定“一个模块应该有一个且只有一个更改理由”（Clean Architecture，Martin，第62页）。 SRP适用于模块级别，在应用SRP时，应将重点放在更改原因上。

结论

SOC原则规定，代码工件应允许人们将注意力集中在某个方面。 SRP通过指出在模块级别上我们应该将注意力集中在更改的原因上来具体说明这一点。因此，SRP是SOC。

P.S。为了完整性：通用闭包原则

通用关闭原则（CCP）是在更高级别（组件级别）对SRP的重新声明。 CCP指出，出于相同原因在相同时间更改的类应收集到相同的组件中（Clean Architecture，第105页）。 CCP是SOC的另一个示例。