SOLID 原则中的 SRP 会导致 Lasagna Code 吗?

Does SRP in SOLID principle lead to Lasagna Code?

有了 SOLID 原则,尤其是 SRP,我们有很多 classes..
我的意思是,这就像你想要建立一个数据库class
那么,你有
DatabaseHandler class 处理数据库(select、插入、更新、删除等),

DatabaseAdapter class扩展PDO class(可以在构造中设置首选默认模式,一个新的prepare方法,直接准备语句,绑定它参数,并执行它,

QueryBuilder Class 是 SelectStatementBuilder Class、InsertStatementBuilder Class、DeleteStatementBuilder Class、UpdateStatementBuilder Class(构建 SQL 语句)的父项,

表达式 Class 构建 WHERE 子句中所需的表达式

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

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

SRP 原则的实施会导致 Lasagna 代码吗? Lasagna 代码可以吗?

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

Uncle Bob defined SRP 为:

A class should have only one reason to change.

当采用错误的粒度级别时,SRP 可以解释为 class 应该只做一件非常小的、低级别的事情,导致过度抽象,没有明显的好处。通读他的论文,您会注意到 "reason to change" 是在 user/client/consumer 需求级别定义的。一个简单的例子是,如果我的 UI 要求的变化导致我改变包含一些数据访问层代码的 class,那么 class 有不止一个改变的理由(即UI 和数据访问)违反了 SRP。

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