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

Question

假设我们正在设计一个执行CRUD（创建，读取，更新和删除）操作的UserServiceImpl类。在我看来，创建，读取，更新和删除是改变类的四个原因。这个类是否违反了单一责任原则？如果违反， 然后我们应该有四个类，如CreateUserServiceImpl，ReadUserServiceImpl， UpdateUserServiceImpl和DeleteUserServiceImpl。拥有很多东西不是一件坏事 类？

假设我为创建，读取，更新和删除操作定义了4个接口 服务类实现所有四个接口。现在我只能有一个 实现类，但通过分离他们的接口我已经将概念分离为 就其他应用程序而言。这是正确的方式还是你看到了一些问题 在它？

Answer 1

这就是我喜欢的模式和原则 - 它们是一种让每个人都不同意软件设计的方式，同意： - ）

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

模式和原则是伟大的事情，但如果使用不当，他们可以解决一个简单的问题，就像没有它们一样复杂。

Answer 2

  

在我看来，创建，阅读，更新和删除是四个原因   要改变的阶级。

为什么？

如果我有一个Stack课程，该课程有Push和Pop个原因需要更改吗？

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

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

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

Answer 3

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