Oop 如何将单一责任原则应用于服务类

假设我们正在设计一个UserServiceImpl类，它执行CRUD（创建、读取、更新和删除）操作。在我看来，创建、读取、更新和删除是类更改的四个原因。该类是否违反了单一责任原则？如果违反了,， 那么我们应该有四个类，比如

CreateUserServiceImpl

，

ReadUserServiceImpl

，

UpdateUserServiceImpl

和

DeleteUserServiceImpl

。有很多钱不是太过分了吗 上课

假设我为创建、读取、更新和删除操作以及我的 服务类实现了所有四个接口。现在我只能有一张单人床 实现类，但通过分离它们的接口，我将概念解耦为 就应用程序的其余部分而言。这是正确的方法还是你看到了一些问题

---

在it中？

在服务负责单一类型的数据服务或业务信息之前，它不会违反单一责任原则。

这就是我喜欢模式和原则的原因-它们是每个人在软件设计上意见分歧的一种方式，就像同意一样：-）

我的观点是以任何方式构建类，使其成为一个可用且易于理解的类——这取决于类所处的复杂性和上下文。通过一个简单的实现和上下文，一个类就可以了。您可以说它确实遵守SRP，因为它的责任是管理积垢操作。但是如果实现很复杂，或者有很多共享代码适合放在抽象父类中，那么可能有4个单独的类，每个CRUD操作一个更合理。这都是关于你如何看待它

模式和原则是伟大的东西，但如果使用不当，它们会使一个简单的问题变得和没有它们一样复杂

在我看来，创建、读取、更新和删除是导致错误的四个原因 课堂需要改变

为什么?

如果我有一个

堆栈

类，

Push

和

Pop

类更改的原因是什么

我不这么认为。这是人们对堆栈执行的两个标准操作。与CRUD相同，它是一个简单的、已建立的、众所周知的数据存储操作集

现在，底层存储技术本身就是类更改的原因。也就是说，如果您的CRUD实现被硬编码为仅与MS SQL 6.0数据库的特定实例一起工作，那么您违反了SRP，并且该类将不容易重用或可扩展

---

关于4个接口，这更接近于另一个可靠的原则，这里的需求取决于数据存储的使用模式。例如，如果某些类只需要从数据存储中读取数据，那么只使用Read方法提取接口并请求该接口作为此类方法的参数是完全有意义的。通过分离这个接口，您可以在以后单独实现它。谁知道呢，也许对于只读客户机，您可以发出更好的优化查询或使用内存缓存，但如果不行，您可以将实现此接口的默认数据存储实例传递给他们。

谢谢您的回答。我已经更新了问题。现在设计好了吗？