我试图理解单一责任原则。我有以下问题。
单一职责原则 (SRP) 指出，永远不应该有 改变班级的原因不止一个。 通常我们的 Resource、Service 和 Repository 类有 创建、读取、更新和删除方法。我们正在将每个班级更改为 修改任何这些操作的代码。是否违反 SRP？我们需要 每个动作都有单独的类？
当我运行 sonar lint 时，我看到了以下消息。
类不应与太多其他类耦合。
这里我使用 spring DI 注入其他类。有没有限制 依赖数量？
我可能错过了这个概念的症结所在。请提出一个很好的资源，通过示例更好地理解这个概念
【问题讨论】：
标签： spring solid-principles single-responsibility-principle
SRP 声明类应该只做一件事，比如在存储库的情况下持久化实体。我猜你在这里混淆了“类”和“对象”：如果你有几个方法可以改变 object 的状态，这可能符合 SRP。然而，存储库 class 更改的唯一原因应该与其目的有关，即在这种情况下持久化或检索实体。
关于Single Responsibility Principle 的维基百科文章说得很好。
第二点：没有一个类可以拥有的最大依赖项数量，但如果有很多依赖项，这可能是设计缺陷的标志。
【讨论】：
单一职责原则 (SRP) 指出，应该 改变课程的理由不止一个。
单一职责原则并不意味着组件/类的单一方法或单一类型的操作。
这意味着在某一事项范围内的单一职责。
持久性操作是同一问题的一部分。
所以把它们都放在一个类中并不违反必要的原则。
现在，如果您有十几个特定的数据库操作，那么将它们划分为具有明确定义的职责（例如选择操作、更新操作等）的不同类是有意义的。
通常我们的 Resource、Service 和 Repository 类有 创建、读取、更新和删除方法。我们正在将每个班级更改为 修改任何这些操作的代码。是否违反 SRP？
这些是不同的层。
如果您更改层的模型，其他层的模型通常会在数据在层之间传递时受到影响。
就像您在数据库中添加信息一样，如果您想查看/操作它们，则需要更改您的 GUI 和您的处理。
现在，如果您更改层的实现，其他层应该没有或只有很少的后果。
【讨论】：