SOLID - SRP，一份工作或改变的一个原因[关闭]

Question

互联网上有很多关于 SRP 的混淆。

SRP 是否需要：

1. 类/函数应该做一项工作？
2. 类/函数应该只有一个改变的理由（我们没有 不在乎我们的班级正在执行多少工作，至少当我们 考虑 SRP）

例如。

假设我们有一个类执行大量工作/作业（我知道这很糟糕，我们不应该把所有东西都放在一个类中）

另外，我们假设这个类服务于一个特性，而这个特性只有一个改变的原因，即改变的原因只能来自一个参与者（例如我们的 CTO）

此代码是否仍适用于 SRP？

另外引用Clean Architecture by Robert C. Martin

SOLID 原则、单一职责原则 (SRP) 可能 是最不被理解的。这可能是因为它有一个 特别不恰当的名字。程序员太容易了 听到这个名字，然后假设它意味着每个模块都应该 只做一件事。

别搞错了，有这样的原则。一个函数应该做 一件，也是唯一一件。我们在重构时使用该原则 大功能变成小功能；我们在最低级别使用它。 但这不是 SOLID 原则之一——它不是 SRP。

Answer 1

一如既往，视情况而定。 “单一职责”的意思就是，对一件事负责。

“一件事”可能是一个狭窄的领域或某种广泛的领域。一个简单的例子：

想象一个计算字符串加密签名的类和另一个加密字符串的类。两个班级都尊重 SRP，因为他们每个人都只做一件事。

如果您使用两种方法将它们绑定在一个类中，一种用于加密字符串，另一种用于计算签名，那么您显然违反了 SRP。因为加密和签名没有关系。

但是现在想象一下，您有一个系统可以交换符合某些标准的签名和加密字符串。所以当然这两个函数是相关的，一个类必须处理这两个操作。

这个类的客户甚至对签名和加密之间的关系不感兴趣。客户端只需提供一个准备传输的字符串，然后类对字符串进行签名和加密。所以这个类当然尊重 SRP，不管做两件事，签名和加密。

回到你的（坏的）例子，这个类执行了大量的工作/工作。当班级执行的工作相关时，SRP 就有可能受到尊重。但是当工作不相关时，该类显然违反了SRP。