php - SOLID 原则中的 SRP 会导致 Lasagna Code 吗？

Question

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

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

QueryBuilder 类是 SelectStatementBuilder 类、InsertStatementBuilder 类、DeleteStatementBuilder 类、UpdateStatementBuilder 类(用于构建 SQLStatement)的父类，

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

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

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

SRP 原则的实现会导致 Lasagna 代码吗？ Lasagna 代码可以吗？

Answer 1

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

Uncle Bob defined SRP作为:

A class should have only one reason to change.

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

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