Oop 当我试图遵循坚实的原则时，我的课堂设计有多精细？

我有一个客户端注册接口，名为IRegistrationService。它包含一个名为Register的方法，并通过类registationservice实现。例如，如果我想拥有用于删除、更新和检索的方法，我会为每个操作创建一个单独的接口，例如IDeletionService、IUpdateService、IRetrieveService，还是将所有方法都放在IRegistrationService中。我之所以这样问，是因为这是坚实的原则，特别是SRP原则似乎要问的问题。

说明单一责任原则的一种方式是，一个类应该只有一个改变的理由。这并不一定意味着它只做一件事，而是只涉及一个责任领域

---

所以，您的注册服务可以了解所有获得注册的人，我会在其中包括删除、更新和检索注册。如果注册过程发生变化（例如，您决定向所有新用户或更新用户发送电子邮件），则类会发生变化。但是，注册电子邮件发送方式的实现细节不属于此服务——这可能是类可能更改的第二个原因（例如，您意识到您希望通过外部SMTP服务器而不是本地发送电子邮件，或者通过SMS而不是电子邮件等）

所以在你的回答中，Registration封装了RegisterUser、DeleteUser、UpdateUser方法，但是如果我想通过电子邮件或Sms向用户发送通知，我可能应该有另一个类，叫做UserNotifications，它处理消息。我没听错吧？你说的还有一件事让我很反感，那就是这个班没有做一件事，它处理的是一个责任范围。你说的球体是什么意思？你有一个例子吗？感谢大多数坚实的原则都非常具体，但SRP有些主观。有能力的开发人员对什么构成单一责任，或者正如JacobM所说，责任的“范围”有不同的看法。也就是说，我相信基于您给出的UserNotifications示例，您的理解是正确的。也许SRP最好的解释是考虑一个明显违反它的行为：一个提供注册客户、计算他们的抵押贷款利息并通知他们是否延迟付款的方法的类将承担多重责任。大家一致认为，定义责任范围可能很难。并同意用户通知将是一个单独的类。思考这个问题的一种方法是，思考在确定一个类应该如何工作时，您将进行的对话类型。您将有一种类型的对话（可能是与您的客户）来考虑注册过程的更改，还有一种不同的对话来确定（比如）注册时要使用什么数据库驱动程序进行连接。一个班级不应该同时知道这两件事。