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

发布时间：2020-12-14 04:57:18 所属栏目：百科来源：网络整理

导读：假设我们正在设计一个执行CRUD(创建,读取,更新和删除)操作的UserServiceImpl类.在我看来,创建,更新和删除是改变类的四个原因.这个类是否违反了单一责任原则？如果违反, 那么我们应该有四个类,比如CreateUserServiceImpl,ReadUserServiceImpl, UpdateUserServ

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

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

解决方法

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

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

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

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!