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

Question

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

Answer 1

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

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

来自here。

Answer 2

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

Answer 3

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

差异

• SRP属于类级别，但SoC位于每个计算机程序，抽象......或有时是架构级别。
• SRP是关于（如何不是什么）将您的域划分为具有一个责任（一个改变的原因）的内聚类的质量。另一方面，SoC是一个将上下文分成不同部分的设计原则，因此每个部分都解决了一个单独的问题（不是如何），因为有很多工具（例如类，函数，模块，包，等等）。 ..）达到这个目标的不同层次。
• SRP的概念基于内聚力（高内聚力），而SoC接近分子，分而治之（D＆C），......在每个抽象层次。
• SoC是一个很好的设计原则来应对复杂性，例如抽象，而要达到单个负责的类，你可以使用SoC原理作为一个很好的解决方案。因为，如果你能从该类中提取另一个责任（关注），那么了解一个类有多个责任的方法就是这样。

相似

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

Answer 4

回答：

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

单一责任原则（SRP）用于讨论较低级别的SoC，例如在课堂上

---

想一想的方法：

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 5

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 6

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

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

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

Answer 7

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

Answer 8

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

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

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

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

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

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

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

Answer 9

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

“关注”=“不同特征”=“不同部分”

“关注”在高层和低层均有效

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

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

结论

• 单一责任原则适用于基本单位 - >低水平工作
• 关注点分离在高层和低层都有效
• SRP和SoC协同工作以分离关注点。他们是 在低级别完全相同

Answer 10

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

Answer 11

由于之前的答案都没有引用创建Single Responsibility Principle的罗伯特·马丁，我认为这里需要一个更权威的答案。

Martin对SRP的启发来自David Parnas，Edsger Dijkstra（创造了“关注点分离”一词）和Larry Constantine（创造了耦合和凝聚力这两个术语）。 Martin将他们的想法整合到SRP中。

单一责任原则的另一个措辞是：

将出于同样原因而改变的事物聚集在一起。将那些因不同原因而改变的事物分开。

如果你想到这一点，你会发现这只是定义内聚和耦合的另一种方式。我们希望增加因同样原因而改变的事物之间的凝聚力，并且我们希望减少因不同原因而改变的事物之间的耦合。

但是，当你考虑这个原则时，请记住改变的原因是人。是要求变更的人。并且您不希望通过将许多不同人关心的代码混合在一起来混淆那些人或者您自己。

对于最初的问题，SRP和SoC之间的细微差别在于，Martin将术语“关注”改进为人。

Answer 12

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