单一责任原则与关注点分离的区别
单一责任原则和关注点分离有什么区别？
What is the difference between Single Responsibility Principle and Separation of Concerns?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
单一责任原则和关注点分离有什么区别？
What is the difference between Single Responsibility Principle and Separation of Concerns?
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（13）
来自 这里。
From here.
单一职责原则和关注点分离实际上是同一回事。
当然，您可能会陷入学术讨论中，试图找出两者之间的某种差异，但为什么呢？出于所有意图和目的，它们描述的是同一件事。最大的问题是人们太想知道“关注点”和“责任”是什么，以至于他们可能错过了 SRP 和 SoC 背后的重要理念。
这个想法只是将你的代码库分割成松散耦合的、独立的部分。这允许多个开发人员在不同的部分上工作而不会互相影响，还允许单个开发人员修改一个孤立的部分而不会破坏另一个部分。
这应用于模块级别，例如MVC是一种促进SRP和SoC的架构模式。代码库被分成独立的模型、视图和控制器。这样，视图的修改就可以独立于模型来完成。两者并没有可怕地交织在一起。
在较低级别，这也应该应用于类。不要将数十个方法放在一个类中，而是将代码分成几个。出于同样的原因。
此外，即使在方法级别，也将大方法拆分为更小的方法。
原则。 SRP 是一个原则，而不是一个规则，所以你不必（阅读：不能/不应该）极端地严格遵循它。例如，这并不意味着走得太远，每个类中只有一个七行方法。它只是意味着将代码分割成独立部分的一般原则。关键是它将带来更好的代码库和更稳定的软件。
The Single Responsibility Principle and Separation of Concerns are really the same thing.
Sure, you can get bogged down in an academic discussion trying to tease out some kind of difference between the two, but why? For all intents and purposes, they describe the same thing. The biggest problem is people get so caught up in wanting to know exactly what a "concern" and "responsibility" are, that they perhaps miss the important idea behind SRP and SoC.
That idea is simply to split your codebase into loosely coupled, isolated parts. This allows multiple developers to work on different parts without affecting each other, it also allows a single developer to modify one isolated part without breaking another.
This is applied at the module level, e.g. MVC is an architectural pattern promoting SRP and SoC. The codebase is split out into isolated models, views and controllers. That way, the modification of a view can be done independently of a model. The two aren't horrifically intertwined.
At a lower level, this should be applied to classes too. Instead of putting dozens of methods in a single class, split the code out into several. For the same reasons.
Also, even at a method level, split large methods out into smaller methods.
In principle. SRP is a principle, not a rule, so you don't have to (read: can't/shouldn't) follow it religiously to the extreme. It doesn't mean going too far and having only one seven line method in each class, for example. It just means a general principle of splitting out code into isolated parts. The point is it will lead to a better codebase and more stable software.
关注点分离与单一职责原则（SoC 与 SRP）
来自链接的文章：
关注点分离 (SoC) – 是将计算机程序分解为不同功能的过程，功能上的重叠尽可能少。关注点是程序中任何感兴趣的部分或焦点。通常，关注点是功能或行为的同义词。
http://en.wikipedia.org/wiki/Separation_of_concerns
单一职责原则 (SRP) ) – 每个对象都应该有一个单一的职责，并且它的所有服务都应该与该职责紧密结合。在某种程度上，内聚被认为是 SRP 的同义词。
http://en.wikipedia.org/wiki/Single_responsibility_principle
Separation of Concern vs Single Responsibility Principle ( SoC vs SRP )
From the linked article:
Separation of Concerns (SoC) – is the process of breaking a computer program into distinct features that overlap in functionality as little as possible. A concern is any piece of interest or focus in a program. Typically, concerns are synonymous with features or behaviors.
http://en.wikipedia.org/wiki/Separation_of_concerns
Single Responsibility Principle (SRP) – every object should have a single responsibility, and that all its services should be narrowly aligned with that responsibility. On some level Cohesion is considered as synonym for SRP.
http://en.wikipedia.org/wiki/Single_responsibility_principle
在我看来，单一职责原则是实现关注点分离的工具/习惯之一。
In my opinion Single Responsibility Principle is one of the tools/idioms to achieve Separation of Concerns.
由于之前的答案都没有引用 Robert Martin，他创建了 单一职责原理，我觉得这里需要一个比较权威的答案。
Martin 对 SRP 的灵感来自 David Parnas、Edsger Dijkstra（他创造了术语“关注点分离”）和 Larry Constantine（他创造了术语“耦合”和“内聚”） ）。马丁将他们的想法整合到了 SRP 中。
对于最初的问题，SRP 和 SoC 之间的细微差别在于 Martin 改进了术语“关注点”以指代“人”。
Since none of the previous answers quote Robert Martin, who created the Single Responsibility Principle, I think a more authoritative answer is needed here.
Martin's inspiration for the SRP was drawn from David Parnas, Edsger Dijkstra (who coined the term Separation of Concerns) and Larry Constantine (who coined the terms Coupling and Cohesion). Martin consolidated their ideas into the SRP.
To the original question, the minor difference between the SRP and SoC is that Martin refined the term concerns to refer to people.
单一职责规定对象负责单个工作单元。
关注点分离指出应用程序应拆分为功能重叠尽可能少的模块。
类似的最终结果...略有不同的应用程序。
Single Responsibility states that an Object be responsible for a single unit of work.
Seperation of Concerns states that applications should be split in to modules whose functionalities overlap as little as possible.
Similar end results...slightly different applications.
关注点分离 (SoC)。将您的应用程序划分为不同的功能，并尽可能减少功能重叠。 （微软）。
“关注”=“鲜明特征”=“鲜明板块”
“关注”在高层和低层都起作用
单一职责原则每个模块或类都应该对软件提供的功能的单个部分负责，并且该职责应该完全由类封装。其所有服务都应与该责任紧密结合。 （维基百科定义）
“责任”=“改变的原因”改变什么？ “软件提供的功能的单个部分” = 基本单元
结论
单一职责原则适用于基本单元 ->在低层工作
关注点分离在高级别和低级别都工作
SRP 和 SoC 一起工作以实现关注点分离。他们是
在低级别上完全相同
Separation of concerns (SoC). Divide your application into distinct features with as little overlap in functionality as possible. (Microsoft).
“Concern” = “distinct feature” = “distinct section”
“Concern” works at both high and low levels
Single responsibility principle states that every module or class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility. (Wikipedia definition)
“Responsibility” = “reason to change” change what? “a single part of the functionality provided by the software” = Basic Unit
Conclusion
Single Responsibility Principle works on basic units -> works at low level
Separation of Concerns works at both high and low levels
SRP and SoC work together for separation of concerns. They are
exactly the same at low level
关注点分离是一个过程；单一职责原则是一种设计/架构哲学。它们并不是完全脱节的，但它们有不同的目的。
Separation of Concerns is a process; the Single Responsibility Principle is a design / architecture philosophy. They're not completely disjoint, but they serve different purposes.
类似但是：SoC与关注点相关：将一个复杂的问题分解为几个关注点，SRP就是只有一个责任。
Similar but: SoC is related to concerns: to break down a complex problem into several concerns, SRP is to have just one responsibility.
SRP 和 SOC 在不同的抽象级别上工作。这两种情况的目的都是为了减少耦合，增强内聚。 SRP更多地在对象级别上工作，而SOC也可能在功能级别的实现上工作。一个函数可以由一个对象实现，也可以由多个对象实现。因此，两个原则的耦合和内聚可能不同。
SRP and SOC work on different level of abstraction. The purpose is in both cases to reduce the coupling and strengthen the cohesion. While SRP works more on an object level, SOC may also work on the implementation of function level. A function can be implemented by one object but also by several objects. Therefore the coupling and the cohesion of both principles may differ.
我尝试对关注点分离（SoC）和单一职责原则（SRP）进行比较。
差异
SRP 处于类级别，但 SoC 位于每个计算机程序、抽象……有时甚至是架构级别。
SRP 是关于将您的域划分为只有一项职责（一个更改理由）的内聚类的质量（如何而不是是什么）。另一方面，SoC 是一种将上下文分成不同部分的设计原则，这样每个部分都解决一个单独的问题（什么而不是如何），因为有很多工具（例如类、函数、模块、包、. ..）以不同的水平实现这一目标。
SRP的概念是基于内聚（高内聚），而SoC在各个抽象层次上接近于Molecularity、分而治之（D&C）……。
SoC 是一个很好的设计原则，可以应对复杂性（例如抽象），而要达到单一负责的类，您可以使用 SoC 原则作为一个很好的解决方案。因为，知道一个类具有多个职责的一种方法是，您是否可以从该类中提取另一个职责（关注点）。
相似之处
I tried to draw a comparison between Separation of concerns(SoC) and Single Responsibility Principle(SRP).
Differences
The SRP is at the class level, but SoC is in each computer program, abstraction ... or sometimes architectural level.
The SRP is about the quality of (how not what) dividing your domain into cohesive classes which have just one responsibility (one reason to change). In other side, SoC is a design principle for separating a context into distinct sections, such that each section addresses a separate concern(what not how), as there are a lot of tools (for example classes, functions, modules, packages, ...) to reach this goal different levels.
The concept of SRP is based on the cohesion (high cohesion), whereas SoC is close to Molecularity, divide and conquer (D&C), ... in each level of abstraction.
SoC is a good design principle to cope complexity, such as abstraction whereas to reach single responsible classes you can use SoC principle as a great solution. As, a way to know that a class has more than one responsibility is if you can extract another responsibility(concern) from that class.
Similarities
答案：
关注点分离 (SoC) 是一个更通用的术语 - 它可以应用于系统级别或较低级别，例如类（甚至是一个类中的方法）。类）
单一职责原则（SRP）用于在较低级别讨论 SoC，例如在类中
思考它的方法：
在较低级别，SoC和 SRP 是同义词。因此，您可以说 SRP 是一个多余的术语 - 或者 SoC 应该仅用于讨论系统级别
鉴于 (1)，术语 SoC 有点含糊。您需要上下文才能了解讨论是关于高级 SoC 还是低级 SoC
要记住，SRP 仅是较低级别的术语，请考虑一下：在日常语言中，“责任”通常是明确定义的 SRP 更适合讨论系统级别
SoC 在某种意义上是比 SRP 更强的要求/原则，因为它适用于系统层面，而要真正实现系统层面还必须用到系统组件的开发。也就是说，高级别的 SoC 意味着较低级别的不错的 SoC/SRP - 但反之则不然，也就是说，较低级别的 SoC/SRP 并不意味着 SoC 或任何下一个更高级别的东西，更不用说涵盖系统。有关在方法级别实现但随后在类级别违反的 SoC/SRP 示例，请查看此 Artur Trosin 的博客文章。
Answer:
Separation of Concerns (SoC) is a more versatile term - it can be applied at the system level or at lower levels such as classes (or even the methods within a class)
Single Responsibility Principle (SRP) is used to discuss SoC at the lower levels e.g. in a class
Ways to think about it:
At the low level, SoC and SRP are synonymous. So you could say SRP is a redundant term - or that SoC should only be used to discuss the system level
Given (1), the term SoC is somewhat ambiguous. You need context to know whether the discussion is about high level SoC or lower level SoC
To remember that SRP is the term for only lower levels, think of this: in everyday language, a "responsibility" is usually a well-defined thing that can be tied to specific code, whereas "concerns" are usually kind of vague and may encompass a bunch of related things, which is perhaps why SoC is a more natural fit for discussing the system level than is SRP
SoC is in some sense a stronger requirement/principle than SRP because it applies at the system level, and to be truly achieved at the system level must also be used in the development of the system components. That is, a high level of SoC implies decent SoC/SRP at the lower levels - but the reverse is not true, that is, lower level SoC/SRP does not imply SoC or anything at all for the next higher level, never mind the encompassing system. For an example of SoC/SRP that is achieved at the method level, but then violated at the class level, check out this Artur Trosin's blog post.
关注点分离
关注点分离 (SOC) 原则指出，代码工件应该允许人们将注意力集中在某个方面。代码工件可以是任何东西，从特定函数到类，或整个包，甚至整个应用程序。 SOC 原理可以应用于应用程序中的每个架构级别。应用SOC的架构的示例是分层架构。
单一职责原则
单一职责原则 (SRP) 指出“模块应该有一个且只有一个更改理由”（Clean Architecture，Martin，第 62 页）。 SRP 适用于模块级别，应用 SRP 时应重点关注更改的原因。
结论
SOC 原则指出，代码工件应该允许人们将注意力集中在某个方面。 SRP 通过指出在模块级别我们应该将注意力集中在更改的原因上来具体说明这一点。因此，SRP 是一个 SOC。
PS 为了完整性：共同闭合原则
共同闭合原则 (CCP) 是在更高级别（组件级别）上对 SRP 的重述。 CCP 指出，出于相同原因且同时发生变化的类应该聚集到相同的组件中（Clean Architecture，第 105 页）。 CCP 是 SOC 的另一个例子。
Separation of Concerns
The Separation of Concerns (SOC) principle states that a code artifact should allow one to focus one's attention upon a certain aspect. A code artifact can be anything, from a specific function, to a class, or a whole package, or even an entire application. The SOC principle can be applied to every architectural level in one's applications. An example of an architecture where SOC is applied is a layered architecture.
Single Responsibility Principle
The Single Responsibility Principle (SRP) states that "A module should have one, and only one, reason to change" (Clean Architecture, Martin, p. 62). The SRP applies to the module level and when applying the SRP one should be focused on the reason to change.
Conclusion
The SOC principle states that a code artifact should allow one to focus one's attention upon a certain aspect. The SRP makes this concrete by stating that at the module level we should focus our attention at the reason of change. Thus the SRP is a SOC.
P.S. For completeness: the Common Closure Principle
The Common Closure Principle (CCP) is a restatement of the SRP at an even higher level, the component level. The CCP states that classes that change for the same reasons and at the same times should be gathered into the same components (Clean Architecture, p. 105). The CCP is another example of a SOC.