OCP 是否违反了 Clean Architecture 中的 SRP？
Does OCP violates SRP in the Clean Architecture?
最近我正在阅读 Robert Martin 的 Clean Architecture。
我对几个 SOLID 原则的定义有一些误解。正是单一职责原则和Open/Closed原则。
好吧，对于第一个，我们有以下内容
A class (module) should have only one reason to change
其中 原因 表示 演员。听起来很清楚。
继续下一个 - OCP。这里有这样的例子
误解的部分是Database和Interactor的关系。我们通过Financial Data Mapper在Database组件中实现了Financial Data Gateway接口，所以我们有两个模块一个职责。似乎违反了 SRP。
我是对的还是为了正确理解而遗漏了一些东西？
我想强调的是，所列的设计方法既不是面向对象的，也不是适合大多数（如果不是全部）情况的良好体系结构。 Here 是我的一篇文章，详细说明了为什么会这样。
单一职责原则也有多种解释，有时甚至相互矛盾。它应该在面向对象的上下文中意味着基本上是强内聚和松散耦合。这是我的 slidedeck 从实用的角度解释所有这些。
因此，恕我直言，我认为您可能对 SRP、OCP、"Clean Architecture" 的实用性或可行性以及一般的面向对象有错误的概念。
综上所述，答案是：你的问题的语法完全错误。没有 "SRP violation" 这样的东西。 SRP 的定义非常松散，即使您选择一种解释，它也不是二元的。这是一个严重依赖于需求和上下文的量表，不能（不应该）单独评估。
最近我正在阅读 Robert Martin 的 Clean Architecture。
我对几个 SOLID 原则的定义有一些误解。正是单一职责原则和Open/Closed原则。
好吧，对于第一个，我们有以下内容
A class (module) should have only one reason to change
其中 原因 表示 演员。听起来很清楚。
继续下一个 - OCP。这里有这样的例子
误解的部分是Database和Interactor的关系。我们通过Financial Data Mapper在Database组件中实现了Financial Data Gateway接口，所以我们有两个模块一个职责。似乎违反了 SRP。
我是对的还是为了正确理解而遗漏了一些东西？
我想强调的是，所列的设计方法既不是面向对象的，也不是适合大多数（如果不是全部）情况的良好体系结构。 Here 是我的一篇文章，详细说明了为什么会这样。
单一职责原则也有多种解释，有时甚至相互矛盾。它应该在面向对象的上下文中意味着基本上是强内聚和松散耦合。这是我的 slidedeck 从实用的角度解释所有这些。
因此，恕我直言，我认为您可能对 SRP、OCP、"Clean Architecture" 的实用性或可行性以及一般的面向对象有错误的概念。
综上所述，答案是：你的问题的语法完全错误。没有 "SRP violation" 这样的东西。 SRP 的定义非常松散，即使您选择一种解释，它也不是二元的。这是一个严重依赖于需求和上下文的量表，不能（不应该）单独评估。