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

Question

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

Answer 1

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

来自链接的文章：

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

单一职责原则 (SRP) – 每个对象都应该有单一职责，并且它的所有服务都应该与该职责紧密结合。在某种程度上，凝聚力被认为是 SRP 的同义词。 http://en.wikipedia.org/wiki/Single_responsibility_principle

Answer 2

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

Seperation of Concerns 规定应用程序应拆分为功能尽可能少重叠的模块。

相似的最终结果...略有不同的应用程序。

Answer 3

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

Answer 4

关注点分离是一个过程；单一职责原则是一种设计/架构哲学。它们并非完全不相交，但它们的用途不同。

Answer 5

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

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

来自here。

Answer 6

类似但：SoC 与关注点相关：将一个复杂问题分解为多个关注点，SRP 只需承担一项责任。

Answer 7

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

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

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

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

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

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

原则上。 SRP 是一项原则，而不是规则，因此您不必（阅读：不能/不应该）虔诚地遵循它。这并不意味着走得太远，例如每个类中只有一个七行方法。它只是意味着将代码拆分为独立部分的一般原则。关键是它会带来更好的代码库和更稳定的软件。

Answer 8

SRP 和 SOC 在不同的抽象级别上工作。在这两种情况下，目的都是为了减少耦合和加强内聚。虽然 SRP 更多地在对象级别上工作，但 SOC 也可能在功能级别上工作。一个功能可以由一个对象实现，也可以由多个对象实现。因此，这两个原则的耦合和内聚可能不同。

Answer 9

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

“关注”=“独特特征”=“独特部分”

“关注”在高水平和低水平都起作用

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

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

结论

• 单一职责原则适用于基本单元 -> 工作在低级别

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

• SRP 和 SoC 协同工作以分离关注点。他们是
  低级完全一样

Answer 10

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

区别

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

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

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

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

相似之处

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

Answer 11

由于之前的答案都没有引用创建Single Responsibility Principle 的 Robert Martin，我认为这里需要一个更权威的答案。

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

单一职责原则的另一种说法是：

将因相同原因而发生变化的事物汇总在一起。将那些因不同原因而改变的事物分开。

如果您考虑这一点，您会意识到这只是定义内聚和耦合的另一种方式。我们希望增加因相同原因而发生变化的事物之间的内聚，并希望减少因不同原因而发生变化的事物之间的耦合。

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

对于最初的问题，SRP 和 SoC 之间的细微差别在于 Martin 将 关注 一词提炼为指代人。

Answer 12

答案：

关注点分离 (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 13

关注点分离

关注点分离 (SOC) 原则指出，代码工件应该允许人们将注意力集中在某个方面。代码工件可以是任何东西，从特定函数到类，或整个包，甚至是整个应用程序。 SOC 原则可以应用于应用程序中的每个架构级别。应用 SOC 的架构示例是分层架构。

单一职责原则

单一职责原则 (SRP) 指出“一个模块应该有一个并且只有一个改变的理由”（Clean Architecture, Martin, p. 62）。 SRP 适用于模块级别，在应用 SRP 时，应关注更改的原因。

结论

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

附注为了完整性：通用闭包原则

通用关闭原则 (CCP) 是对 SRP 在更高级别（组件级别）的重述。 CCP 指出，出于相同原因并在同一时间更改的类应该集中到相同的组件中（清洁架构，第 105 页）。 CCP 是 SOC 的另一个例子。