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

Question

假设我们正在设计一个执行CRUD(创建,读取,更新和删除)操作的UserServiceImpl类.在我看来,创建,读取,更新和删除是改变类的四个原因.这个类是否违反了单一责任原则？如果违反,那么,我们应该有四个类,如CreateUserServiceImpl,ReadUserServiceImpl, UpdateUserServiceImpl,和DeleteUserServiceImpl.拥有很多课程不是一种矫枉过正的行为吗？

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

Answer 1

这就是我喜欢模式和原则的原因 - 它们是每个人对软件设计的不同意见和同意的一致方式:-)

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

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

Answer 2

直到服务负责单一类型或业务信息的数据服务，才不违反单一责任原则。