单一责任原则与关注点分离有什么区别？
Answers:
单一责任原则（SRP）-给每个班级一个改变的理由；和“改变的理由” ==“责任”。例如：发票类不负责自行打印。
关注点分离（自1974年起）。关注==系统功能。照顾每个关注点：对于每个关注点，其他关注点都无关紧要。隐藏行为的实现。
从这里。
在我看来，单一责任原则是实现关注点分离的工具/习惯用法之一。
从链接的文章中：
关注点分离（SoC） –是将计算机程序分解为功能尽可能重叠的不同功能的过程。关注点是程序中的任何关注点或关注点。通常，关注与功能或行为同义。 http://en.wikipedia.org/wiki/Separation_of_concerns
单一责任原则（SRP） –每个对象都应负有单一责任，并且其所有服务应与该责任狭义地保持一致。在某种程度上，凝聚力被视为SRP的同义词。 http://en.wikipedia.org/wiki/Single_responsibility_principle
单一责任原则和关注点分离实际上是同一回事。
当然，您可以在学术讨论中陷入困境，尝试找出两者之间的某种差异，但是为什么呢？出于所有意图和目的，它们描述同一件事。最大的问题是人们非常想知道确切的“关注点”和“责任感”，以至于他们可能错过了SRP和SoC背后的重要思想。
这个想法只是将您的代码库分成松散耦合的隔离部分。这使多个开发人员可以在不影响彼此的情况下处理不同的零件，也允许单个开发人员修改一个孤立的零件而不会破坏另一个零件。
这是在模块级别应用的，例如MVC是促进SRP和SoC的体系结构模式。代码库分为独立的模型，视图和控制器。这样，视图的修改可以独立于模型进行。两两不是可怕的交织在一起。
在较低的级别上，这也应应用于类。不要将多个方法放在一个类中，而是将代码分成几个部分。出于同样的原因。
即使在方法级别，也可以将大型方法拆分为较小的方法。
原则上。SRP是一个原则，而不是一条规则，因此您不必（读：不能/不应该）严格遵循它。例如，这并不意味着走得太远，每个类只有一个七行方法。这仅表示将代码拆分为孤立部分的一般原则。关键是它将导致更好的代码库和更稳定的软件。
关注点分离（SoC）。将您的应用程序划分为不同的功能，并尽可能减少功能重叠。（微软）。
“关注” =“明显特征” =“明显部分”
“关注”在高低两方面都起作用
单一责任原则 规定，每个模块或类都应对软件提供的功能的一部分负责，而责任应由类完全封装。它的所有服务都应严格地与这一责任保持一致。（维基百科定义）
“责任” =“改变的理由” 改变了什么？“软件提供的功能的一部分” =基本单元
结论
单一责任原则适用于基本单位->低级适用
关注点分离在高水平和低水平上均有效
SRP和SoC协同工作以分离关注点。它们
在低级时完全相同
由于先前的答案均未引用创建单一职责原则的罗伯特·马丁（Robert Martin），因此我认为这里需要一个更具权威性的答案。
马丁的SRP灵感来自大卫·帕纳斯（David Parnas），埃兹格·迪克斯特拉（Essger Dijkstra）（创造了关注分离的术语）和拉里·康斯坦丁（拉里·康斯坦丁）（创造了耦合和凝聚力的术语）。马丁将他们的想法整合到了SRP中。
单一责任原则的另一种措词是：
将因相同原因而发生变化的事物聚集在一起。分开那些因不同原因而改变的事物。
如果考虑到这一点，您将意识到这只是定义内聚和耦合的另一种方式。我们希望增加由于相同原因而改变的事物之间的凝聚力，并且我们希望减少因不同原因而改变的事物之间的耦合。
但是，在考虑这一原则时，请记住，改变的原因是人。这是人谁请求更改。而且，您不希望通过将许多不同人出于不同原因而关心的代码混合在一起来混淆这些人或您自己。
对于最初的问题，SRP和SoC之间的次要区别是Martin提炼了“关注”一词来指代人。
我试图在关注点分离（SoC）和单一责任原则（SRP）之间进行比较。
差异性
SRP在类级别，但是SoC在每个计算机程序，抽象...或有时在体系结构级别。
SRP是关于将您的域划分为仅具有一种责任（改变的一个原因）的内聚类的质量（而不是什么）的质量。在另一方面，SoC是一种用于将上下文分为不同部分的设计原则，这样，由于存在许多工具（例如类，函数，模块，程序包等），每个部分都解决了一个单独的问题（不是怎么解决）。 ..）以达到不同水平的目标。
SRP的概念基于内聚性（高内聚性），而SoC在每个抽象级别上都接近于分子，分而治之（D＆C），...。
SoC是应对复杂性（例如抽象）的良好设计原则，而要达到单一负责的类，则可以将SoC原则用作出色的解决方案。因此，一种了解一个班级有多个责任的方法是，您是否可以从该班级提取另一个责任（关注）。
相似之处
回答：
关注分离（SoC）是一个更通用的术语-可以在系统级别或较低级别（例如，类（甚至是类中的方法））中应用
单一责任原则（SRP）用于在较低级别（例如在一堂课中）讨论SoC
思考方式：
在低层，SoC和SRP是同义词。因此，您可以说SRP是多余的术语-或SoC仅应用于讨论系统级别
给定（1），术语SoC有点模棱两可。您需要上下文信息才能知道讨论的是高级SoC还是较低级SoC
要记住SRP仅是较低级别的术语，请考虑一下：在日常语言中，“责任”通常是定义明确的事物，可以与特定代码联系在一起，而“担忧”通常有点含糊，可能包含许多相关的内容，这也许就是为什么SoC比SRP更适合讨论系统级别的原因
从某种意义上说，SoC是比SRP更强的要求/原则，因为它适用于系统级别，并且要在系统级别真正实现，还必须在系统组件的开发中使用。也就是说，高级别的SoC意味着较低级别的SoC / SRP不错-但是事实并非如此，也就是说，较低级别的SoC / SRP并不意味着下一个更高级别的SoC或任何东西。包含系统。有关在方法级别实现但在类级别违反的SoC / SRP的示例，请查看Artur Trosin的博客文章。
关注点分离
关注分离（SOC）原则指出，代码工件应使人们可以将注意力集中在某个方面。代码工件可以是任何东西，从特定的功能到类，整个包，甚至整个应用程序都可以。SOC原理可以应用于一个应用程序中的每个体系结构级别。应用SOC的体系结构示例是分层体系结构。
单一责任原则
单一责任原则（SRP）指出“一个模块应该只有一个变更理由”（Clean Architecture，Martin，第62页）。SRP适用于模块级别，在应用SRP时，应将重点放在更改原因上。
结论
SOC原则规定，代码工件应允许人们将注意力集中在某个方面。SRP通过指出在模块级别上我们应该将注意力集中在更改的原因上来具体说明这一点。因此，SRP是SOC。
PS完整性：共同封闭原则
通用关闭原则（CCP）是SRP在更高级别（组件级别）的重述。CCP指出，出于相同原因在相同时间更改的类应收集到相同的组件中（Clean Architecture，第105页）。CCP是SOC的另一个示例。