Separation of concerns 单一责任原则与关注点分离的区别
单一责任原则和关注点分离之间有什么区别？ 从链接文章中：Separation of concerns 单一责任原则与关注点分离的区别,separation-of-concerns,solid-principles,single-responsibility-principle,Separation Of Concerns,Solid Principles,Single Responsibility Principle,单一责任原则和关注点分离之间有什么区别？ 从链接文章中： 关注点分离（SoC）是将计算机程序分解为不同功能的过程，这些功能的重叠程度尽可能小。关注点是程序中的任何兴趣点或焦点。通常，关注点与功能或行为同义。 单一责任原则（SRP）–每个对象都应该有一个单一的责任，其所有服务都应该与该责任紧密结合。在某种程度上，衔接被认为是SRP的同义词。 单一责任表示一个对象负责单个工作单元 关注点分离表示，应用程序应拆分为功能重叠尽可能少的模块 相似的最终结果…略有不同的应用。在我看来，单一责任原则是实现关
关注点分离（SoC）是将计算机程序分解为不同功能的过程，这些功能的重叠程度尽可能小。关注点是程序中的任何兴趣点或焦点。通常，关注点与功能或行为同义。 单一责任原则（SRP）–每个对象都应该有一个单一的责任，其所有服务都应该与该责任紧密结合。在某种程度上，衔接被认为是SRP的同义词。
单一责任表示一个对象负责单个工作单元 关注点分离表示，应用程序应拆分为功能重叠尽可能少的模块
相似的最终结果…略有不同的应用。在我看来，单一责任原则是实现关注点分离的工具/习惯用法之一。关注点分离是一个过程；单一责任原则是一种设计/架构理念。它们不是完全不相交的，但它们有不同的用途 单一责任原则（SRP）- 给每一个班级一个理由 改变和“改变的理由”== “责任”。例如：发票 类没有责任 打印自己 关注点分离（自1974年起）。 关注点==系统的功能。拿 关注每个问题：针对每个问题 一个担忧，另一个担忧是 无关的隐藏实现 行为
类似但：SoC与关注点相关：要将复杂问题分解为多个关注点，SRP只有一个责任。单一责任原则和关注点分离实际上是一回事 当然，你可能会陷入一场学术讨论，试图梳理出两者之间的某种差异，但为什么呢？出于所有意图和目的，它们描述的都是同一件事。最大的问题是，人们太想知道什么是“关注点”和“责任”，以至于他们可能错过了SRP和SoC背后的重要思想 这个想法就是简单地将代码库拆分为松散耦合的独立部分。这允许多个开发人员在不影响彼此的情况下处理不同的部分，还允许单个开发人员修改一个独立的部分而不破坏另一个 这在模块级应用，例如MVC是一种促进SRP和SoC的架构模式。代码库分为独立的模型、视图和控制器。这样，视图的修改可以独立于模型进行。二者并没有可怕地交织在一起 在较低的级别上，这也应该应用于类。不要将几十个方法放在一个类中，而是将代码分成几个类。出于同样的原因 甚至在方法级别，也可以将大型方法拆分为较小的方法
原则上。SRP是一个原则，而不是一个规则，所以你不必（读：不能/不应该）极端地遵循它。例如，这并不意味着走得太远，每个类中只有一个七行方法。它只意味着将代码分割成独立部分的一般原则。关键是它将带来更好的代码库和更稳定的软件。SRP和SOC在不同的抽象级别上工作。在这两种情况下，目的都是为了减少耦合和加强内聚。虽然SRP更多地在对象级别上工作，但SOC也可能在功能级别的实现上工作。一个函数可以由一个对象实现，也可以由多个对象实现。因此，这两个原则的耦合性和内聚性可能有所不同 关注点分离（SoC）。将应用程序划分为不同的功能，并尽可能减少功能重叠。（微软） “关注点”=“不同功能”=“不同部分” “关注”在高水平和低水平上都有效 单一责任原则规定，每个模块或类应对软件提供的功能的单个部分负责，并且该责任应完全由类封装。它的所有服务都应该与这一责任紧密结合。（维基百科定义） “责任”=“变更原因”变更什么？“软件提供的功能的单个部分”=基本单元 结论
- 单一责任原则在基层工作->在低水平工作
- 关注点的分离在高级别和低级别都起作用
- SRP和SoC合作分离关注点。它们是
在低水平上完全相同
- SRP在类级别，但SoC在每个计算机程序中，抽象。。。或者有时是建筑层次
- SRP是关于如何（而不是什么）将您的域划分为只有一个职责（一个改变的原因）的内聚类的质量。另一方面，SoC是一种设计原则，用于将上下文划分为不同的部分，以便每个部分都解决一个单独的问题（什么而不是如何）