关于SRP，互联网上有很多令人困惑的地方。
SRP是否需要：
例如
让我们假设我们有一个班级完成很多工作/工作（我知道这很糟糕，我们不应该将所有内容都放在一个班级里）
还要假设这一类服务于一项功能，并且该功能仅具有更改的一个原因，即更改的原因只能来自一个参与者（例如我们的CTO）
此代码是否仍适用于SRP？
另外引用Clean Architecture by Robert C. Martin
SOLID原则，单一责任原则（SRP）可能 最少了解。那可能是因为它有一个 名称特别不合适。对于程序员来说太容易了 听到名称，然后假设这意味着每个模块都应 只做一件事。
没错，有这样的原则。一个功能应该做 一件事，唯一的一件事。重构时我们会使用该原理 大功能变成小功能我们在最低级别使用它。 但这不是SOLID原则之一，也不是SRP。
答案 0 :(得分：1)
一如既往，这取决于。 “单一责任”就是要对一件事情负责。
“一件事”可能是狭窄的领域，也可能是广阔的领域。一个简单的例子：
想象一下一个计算字符串的加密签名的类和另一个用于加密字符串的类。这两个类都尊重SRP，因为它们每个都只做一件事。
如果使用两种方法将它们捆绑在一起，一种用于加密字符串，另一种用于计算签名，则显然违反了SRP。因为加密和签名不是在一起。
但是现在想象一下，您有一个系统可以交换符合某些标准的签名和加密字符串。因此，这两个功能当然是相关的，并且一个类必须处理这两种操作。
此类的客户端甚至不关心签名和加密之间的关系。客户端仅提供要准备传输的字符串，并提供类签名并对该字符串进行加密。因此，此类当然不考虑签名和加密两件事而尊重SRP。
回到您的（糟糕的）示例，该类执行大量的工作/工作。当班级执行的工作相关时，就有可能遵守SRP。但是当工作不相关时，班级显然违反了SRP。