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

Question

使用SOLID原则，特别是SRP原则，我们有许多类… 我的意思是，就像你想要构建一个数据库类一样， 然后你会有一个DatabaseHandler类来处理数据库（选择、插入、更新、删除等）， 一个DatabaseAdapter类，它是一个扩展了PDO类的类（可以在构造函数中设置优选默认模式，一个新的prepare方法直接准备语句，将其与参数绑定并执行）， QueryBuilder类是SelectStatementBuilder类、InsertStatementBuilder类、DeleteStatementBuilder类、UpdateStatementBuilder类（用于构建SQLStatement）的父类， Expression类构建WHERE子句中所需的表达式， SQLStatement类（其行为就像普通字符串，但其接口是SQLStatementInterface，因此我们可以知道它是一个SQL语句等）。

我知道如果我深入挖掘并进行重构，会有更多的类出现。

SRP原则的实现是否导致千层饼代码？ 千层饼代码是否正确？

- Terry Djony

Answer 1

一般而言，SRP是一种设计原则，要求您考虑系统的不同职责（也称为变更原因）。其目标是帮助提高系统的内聚性。换句话说，“一起变化的东西，应该放在一起”。 Uncle Bob定义了SRP：

一个类只应该有一个变更的原因。

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

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

- ivan.sim