SOLID 原则中的 SRP 是否会导致千层面代码？

Question

使用 SOLID 原则，尤其是 SRP，我们有很多类..
我的意思是，这就像你想构建一个数据库类
然后，你有
处理数据库的 DatabaseHandler 类（选择、插入、更新、删除等），

DatabaseAdapter 类是扩展的 PDO 类（可以在构造时设置首选的默认模式，一个新的 prepare 方法直接准备语句，将其与参数绑定并执行它，

QueryBuilder 类，它是 SelectStatementBuilder 类、InsertStatementBuilder 类、DeleteStatementBuilder 类、UpdateStatementBuilder 类（用于构建 SQLStatement）的父级，

建立 WHERE 子句所需的表达式的表达式类

SQLStatement 类（它的行为就像一个普通的字符串，但它的接口是 SQLStatementInterface 所以我们可以知道它是一个 SQL 语句等。

而且，我知道如果我深入挖掘它并再次重构，将会有更多类。

SRP 原则实施是否会导致千层面代码？ 千层面码可以吗？

Answer 1

一般来说，SRP 是一种设计原则，需要您考虑系统的不同职责（也就是改变的原因）。它的目标是帮助提高您的系统凝聚力。换句话说，一起改变的事物，会保持在一起。

Uncle Bob defined SRP 为：

一个类应该只有一个改变的理由。

当采用错误的粒度级别时，SRP 可以被解释为一个类应该只做一件非常小的、低级别的事情，导致过度抽象而没有明显的好处。阅读他的论文，您会注意到“改变的原因”是在用户/客户/消费者需求级别定义的。一个简单的例子是，如果我的 UI 要求的更改导致我更改包含一些数据访问层代码的类，那么该类有多个更改原因（即 UI 和数据访问），这违反了 SRP。

在您的情况下，除非您正在构建数据库管理工具，否则没有理由将原始数据库类分解为许多较小的类。如果这是一个典型的（Web）应用程序，那么如果您想更改底层数据库实现（例如在测试期间从 MySQL 更改为内存数据库），那么无论如何都必须替换所有这些类。还不如保持简单。