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

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

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

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

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

模式和原则是很好的事情,但如果使用不当,它们可以解决一个简单的问题,就像没有它们一样复杂.