5

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

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

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

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

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

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

SRP 原则实施会导致千层面代码吗？烤宽面条代码好吗？

4

1 回答 1

5

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

Bob大叔将SRP定义为：

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

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

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

于 2015-05-03T07:23:38.957 回答