单一职责原则和关注点分离有什么区别?
13 回答
单一职责原则(SRP)——给每个班级一个改变的理由;和“改变的原因”==“责任”。例如:发票类不负责打印自己。
关注点分离(自 1974 年起)。关注 == 系统的特性。照顾每一个关注点:对于每一个关注点,其他关注点都无关紧要。隐藏行为的实现。
从这里。
单一职责原则和关注点分离实际上是一回事。
当然,您可能会陷入试图找出两者之间某种差异的学术讨论中,但为什么呢?出于所有意图和目的,它们描述的是同一件事。最大的问题是人们太想知道究竟什么是“关注”和“责任”,以至于他们可能错过了 SRP 和 SoC 背后的重要理念。
这个想法只是将您的代码库拆分为松散耦合的隔离部分。这允许多个开发人员在不影响彼此的情况下处理不同的部分,它还允许单个开发人员修改一个孤立的部分而不破坏另一个部分。
这适用于模块级别,例如 MVC 是促进 SRP 和 SoC 的架构模式。代码库被分成独立的模型、视图和控制器。这样,视图的修改可以独立于模型进行。两个两个并没有可怕地交织在一起。
在较低级别上,这也应该应用于类。与其将几十个方法放在一个类中,不如将代码分成几个。出于同样的原因。
即使在方法级别,也可以将大型方法拆分为较小的方法。
原则。SRP 是一项原则,而不是规则,因此您不必(阅读:不能/不应该)虔诚地遵循它。例如,这并不意味着走得太远并且每个类中只有一个七行方法。它只是意味着将代码拆分为独立部分的一般原则。关键是它会带来更好的代码库和更稳定的软件。
从链接的文章:
关注点分离 (SoC) – 是将计算机程序分解为功能上尽可能少重叠的不同功能的过程。关注点是程序中的任何兴趣或关注点。通常,关注点与特征或行为同义。 http://en.wikipedia.org/wiki/Separation_of_concerns
单一职责原则 (SRP) – 每个对象都应该有单一职责,并且它的所有服务都应该与该职责紧密结合。在某种程度上,凝聚力被认为是 SRP 的同义词。 http://en.wikipedia.org/wiki/Single_responsibility_principle
在我看来,单一职责原则是实现关注点分离的工具/习惯用法之一。
单一职责声明一个对象负责一个单一的工作单元。
关注点分离指出应用程序应拆分为功能尽可能少重叠的模块。
类似的最终结果......略有不同的应用程序。
由于之前的答案都没有引用创建单一责任原则的罗伯特马丁,我认为这里需要一个更权威的答案。
Martin 对 SRP 的灵感来自 David Parnas、Edsger Dijkstra(创造了分离关注点)和拉里康斯坦丁(创造了术语耦合和内聚)。Martin 将他们的想法整合到 SRP 中。
单一职责原则的另一种说法是:
将因相同原因而发生变化的事物聚集在一起。将那些因不同原因而改变的事物分开。
如果您考虑这一点,您会意识到这只是定义内聚和耦合的另一种方式。我们希望增加因相同原因而变化的事物之间的凝聚力,我们希望减少因不同原因而变化的事物之间的耦合。
然而,当你思考这个原则时,请记住改变的原因是人。是人要求改变。而且您不希望通过将许多不同人出于不同原因而关心的代码混合在一起来混淆这些人或您自己。
对于最初的问题,SRP 和 SoC 之间的细微差别是 Martin 将关注这一术语提炼为指人。
关注点分离是一个过程;单一职责原则是一种设计/架构哲学。它们并非完全不相交,但它们服务于不同的目的。
类似但: SoC 与关注点有关:将一个复杂的问题分解为几个关注点,SRP 就是只有一个责任。
SRP 和 SOC 在不同的抽象级别上工作。在这两种情况下,目的都是为了减少耦合和加强内聚。虽然 SRP 更多地在对象级别上工作,但 SOC 也可能在功能级别上工作。一个功能可以由一个对象实现,也可以由多个对象实现。因此,这两个原则的耦合和内聚可能不同。
我试图在关注点分离(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, p. 62)。SRP 适用于模块级别,在应用 SRP 时,应关注更改的原因。
结论
SOC 原则指出,代码工件应该允许人们将注意力集中在某个方面。SRP 通过说明在模块级别我们应该将注意力集中在更改的原因上来具体说明这一点。因此,SRP 是一个 SOC。
PS 为了完整性:通用闭包原则
通用关闭原则 (CCP) 是对 SRP 在更高级别(组件级别)的重述。CCP 指出,出于相同原因并在同一时间更改的类应该集中到相同的组件中(清洁架构,第 105 页)。CCP 是 SOC 的另一个例子。