logo标签列表

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

separation-of-concernssolid-principlessingle-responsibility-principle
110

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

Single Responsibility Principle（SRP）的范围是什么？ - jaco0646
13个回答
51
单一职责原则（SRP）- 让每个类只有一个变化的原因，而“变化的原因”==“职责”。例如：发票类没有打印自己的职责。
关注点分离（自1974年以来）。关注点 == 系统的特征。照顾每个关注点：对于每个关注点，其他关注点都是无关紧要的。隐藏行为的实现。
来自这里。
4
原则上相同，但仅使用单一职责原则似乎不能避免过度分离。过度分离没有过度耦合那么糟糕，但它也很糟糕，因为它增加了软件构建和维护的成本（与过度耦合相同的问题，但原因不同）。单一职责原则要求有两个非常重要的成功因素，至少是根据Robert C. Martin所说的：(1)“关注点”首先是业务级别而不是技术级别；(2)将属于一起的事物分开是一个错误。https://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html - FastAl
那么它们是同一件事情。责任 == 关注 - Juan Perez
在我们现代历史中，SRP是何时被SOC所取代的？ 简而言之，SOC只涉及代码，而SRP则涉及“演员”，即对你编写的代码负责的人。应该有一个这样的“演员”，他是我们代码更改的真相来源。 - Andrey Filyanin
43

单一职责原则和关注点分离其实是同一件事情。

确实，你可以被学术讨论牵扯进去，试图在两者之间找出某种差异，但为什么呢？就所有的目的而言，它们描述的是同一个东西。最大的问题是人们太过于追求要知道"关注点"和"职责"到底是什么，以至于他们可能会错过SRP和SoC背后的重要思想。

这个思想就是将代码库分成松散耦合、隔离的部分。这样允许多个开发人员在不影响彼此的情况下工作，也允许单个开发人员修改一个隔离的部分而不破坏另一个部分。

这应用于模块级别，例如MVC是促进SRP和SoC的架构模式。代码库被拆分成隔离的模型、视图和控制器。这样，可以独立地修改视图，而不影响模型。这两者之间没有可怕的纠缠。

在更低层次上，这也应该应用于类。将几十个方法放在一个类中，不如将代码拆分成几个部分。出于同样的原因。

同时，即使在方法级别上，也要将大型方法拆分成较小的方法。

原则上，SRP是一种原则，而不是一条规则，所以你不必（也不能/不应该）过分地遵循它。这并不意味着要走得太远，并且每个类只有一个七行的方法，例如。它只是意味着将代码拆分成隔离的部分的一般原则。重点是这会导致更好的代码库和更稳定的软件。

21

关注点分离 vs 单一职责原则 (SoC vs SRP)

摘自链接文章:

关注点分离 (SoC) - 是将计算机程序分解成尽可能重叠功能少的不同特性的过程。关注点是程序中任何感兴趣或关注的部分。通常，关注点与功能或行为同义。

http://en.wikipedia.org/wiki/Separation_of_concerns

单一职责原则 (SRP) - 每个对象都应该有一个单一的职责，并且其所有服务都应该与该职责密切对齐。在某种程度上，内聚力被认为是 SRP 的同义词。

http://en.wikipedia.org/wiki/Single_responsibility_principle
5
在这些定义中，哪一种级别的内聚被视为单一职责原则的同义词？我搜索到有许多内聚级别（从低到高）：巧合、逻辑、时间、过程和功能。在这个解释中，它是否仅意味着“功能内聚”？ - limonik
19

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

3
什么意思？可以轻松地创建一个具有不重叠功能（SRP）的应用程序，其中包含许多对象，这些对象具有非分离关注点（!SOC）。 - Andrew Song
9
但是，想象一个具有多个责任但仍遵循关注点分离原则的对象要困难得多。换句话说，为了在所有层面上实现真正的关注点分离，最好遵循单一职责原则。 - BostonLogan
14

单一职责原则指对象应负责一个单一工作单位。

关注分离原则指应用程序应分成模块，其功能尽可能少地重叠。

目的类似...应用略有不同。

对象和模块有什么区别？对我来说，一个模块是一个类，而一个对象可以是一个类或者一个类的实例。 - Rookian
一个模块可以是应用程序中整个类似功能的组成部分...由许多类之间的交互组成（如果您遵循单一职责原则，则每个类都有一个单一职责）。 - Justin Niessner
14
由于之前的回答都没有引用单一职责原则的创造者Robert Martin，因此我认为这里需要一个更权威的答案。
Martin的SRP灵感来源于David Parnas、Edsger Dijkstra（他创造了“关注点分离”这个术语）和Larry Constantine（他创造了“耦合”和“内聚”这两个术语）。Martin将他们的想法整合到了SRP中。
单一职责原则的另一种表述是：
将变化原因相同的东西聚集在一起。将变化原因不同的东西分开。
如果你仔细考虑一下，你会意识到这只是定义内聚性和耦合性的另一种方式。我们希望增加那些因为相同原因而发生变化的事物之间的内聚性，并减少那些因为不同原因而发生变化的事物之间的耦合度。
然而，在思考这个原则时，请记住变化的原因是人。是人要求变化。你不想通过混合许多不同人关心的代码来混淆那些人或自己。
对于原问题，SRP和SoC之间的微小差别在于Martin将“关注点”这个术语改进为指代“人”。
1
R.C.Martin说：“这就是我们分离关注点的原因。” 他所指的“这”是指前一句中的“这”，而前一句中的“这”是指“我们打破他们关心的事情”。 因此，在那篇博客文章中，SoC关乎人。 同时（您的答案来自2019年），R.C.Martin已经出版了《Clean Architecture》一书，在其中他说：“因此，SRP的最终版本是：一个模块应该只对一个参与者负责。” （第62页）。 这很清楚：SRP关乎人。该死！ - Thomas Weller
最近，Martin用相同的观点认可了这个twitter帖子。 - jaco0646
9

关注点分离（SoC）。将应用程序划分为具有尽可能少重叠功能的不同特性。

“关注点” = “独立特性” = “独立部分”

“关注点”在高级和低级别都起作用

单一职责原则指出每个模块或类应该对软件提供的一个功能的一部分负责，并且该职责应完全封装在类中。所有服务都应与该职责紧密对齐。(维基百科定义)

“职责”=“变更原因” 变更什么？“软件提供的一个功能的一部分”=基本单元

结论：

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

  • 关注点分离在高级和低级别都适用

  • SRP和SoC共同实现关注点的分离。它们在低级别完全相同

SRP 在不同的层面上也适用，你在库级别上有更一般的责任，而在类级别上则更具体，在函数级别上则更加具体。 - Phil1970
3

关注点分离 (Separation of Concerns) 是一个过程；单一职责原则 (Single Responsibility Principle) 是一种设计/架构哲学。它们并不完全独立，但是它们的用途不同。

2

我试图比较关注点分离（SoC）和单一职责原则（SRP）之间的差异。

差异

  • SRP是在类级别上，但SoC是在每个计算机程序、抽象层面或有时是架构层面上的。

  • SRP是关于将您的域划分为具有一个责任（一个变化的原因）的凝聚类的质量（如何而不是什么）。另一方面，SoC是将上下文分成不同部分的设计原则，以便每个部分都处理一个单独的问题（是什么而不是如何），因为有许多工具（例如类、函数、模块、包等）可用于达到不同层次的目标。

  • SRP的概念基于内聚性（高内聚性），而SoC接近模块化、分而治之（D&C）等各种抽象级别。

  • SoC是应对复杂性的良好设计原则，例如抽象，而要实现单一职责类，可以使用SoC原则作为一个很好的解决方案。如果您可以从该类中提取另一个责任（关注点），则知道该类具有多个责任。

相似之处

  • 应用这些原则后，您的上下文变得更具可重用性、可维护性、健壮性、可读性等。
2
类似但不同：SoC涉及到关注点（concerns）的分解，将一个复杂问题分解成几个关注点，而SRP则是只有一个职责。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接