单一职责原则 (SRP) 和我的服务等级
我有 YoutubeVideoService 类，它执行 CRUD（创建、读取、更新和删除）操作。在我看来，创建、读取、更新和删除是类更改的四个原因。这个类是否违反了单一职责原则？
如果违反了，那么我们应该有四个类，例如 CreateYoutubeVideoService、ReadYoutubeVideoService、UpdateYoutubeVideoService 和 DeleteYoutubeVideoService。上很多课不是太过分了吗？
I have YoutubeVideoService class which does CRUD(Create, Read, Update, and Delete) operations. In my view Create, Read, Update, and Delete are four reasons for a class to change. Does this class violates Single Responsibility Principle?
If it violates, then should we have four classes like CreateYoutubeVideoService, ReadYoutubeVideoService, UpdateYoutubeVideoService and DeleteYoutubeVideoService. Isn't it an overkill to have lots of classes?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
一个方法应该有多长？可以说没有理由有超过 2 行。但这在某些情况下肯定是矫枉过正了。与建议零售价 (SRP) 相同 - 您必须决定何时适可而止。 CRUD 看起来像是一组内聚的操作，非常适合单个类，因为它们对相同类型的数据进行操作。
How long should a method be? One could say there is no reason to have more than 2 lines. But this is certainly overkill in some situations. Same with SRP - you have to decide when enough is enough. CRUD looks like a cohesive set of operations which are perfectly fit for single class, because they operate on same type of data.
衡量单一职责原则一致性的一个好方法是考虑有多少理由改变这个类。如果您能想到不止一个更改理由，则可能违反了 SRP。
像这样更改 CRUD 类的唯一原因是底层数据结构。所以这尊重建议零售价。
另一方面，如果您在该类中进行任何其他操作（例如，在插入视频之前检查视频长度或类型），则会违反 SRP，因为它可以独立于持久层进行更改。
SRP不是教条，在遵循SOLID原则时，我们总是要小心不要引入不必要的复杂性。根据 Bob Martin 的杰作，谈论何时应该分离两个责任：
A good way of measuring coherence to the Single Responsibility Principle is to think about how many reasons to change this class has. If you can think more than one reason to change, probably it's violating the SRP.
The only reason to change a CRUD class like this, is a change in the underlying data structure. So this respects the SRP.
On the other hand, if you had any other operation in that class (es. checking the video length or type before inserting it), that would violate SRP, since it could change independently from the persistency layer.
SRP is not a dogma, when following SOLID principles, we always have to be careful to not introduce needless complexity. As per Bob Martin's masterpiece, speaking about when two responsibility should be separated:
我认为您在班级级别上将单一责任原则推向了极端，而没有考虑凝聚力。
如果您遵循这条路线，您可以证明拥有大量只包含一两个方法的类是合理的，这反过来又会增加对天空的依赖数量。
我认为 SRP 的精神是尽可能简化，但不要更多。
I think you're taking the Single Reposibility Principle a bit to the extreme on a class level, without taking into consideration cohesion.
If you follow that route, you could justify having lots of classes with just one or two methods, which in turn would increase the number of dependencies to the sky.
I think the spirit of SRP is Simplify as much as you can, but not more.
服务类别是 SRP 杀手。根据定义，它们是操作的聚合 - 这与 SRP 相反。通常，服务的单个方法需要一些依赖关系，所有其他方法可能根本不关心，然后随着每个这样的方法依赖关系的增加，它会导致混乱。管理器、服务，有时是存储库——从依赖关系的角度来看，这些模式显然很糟糕。在命令/查询/请求世界中，您将拥有这 3 个命令和一个刚刚分组到域/目录中的查询。这会带来更干净、更小、更容易阅读和可扩展的代码。还有更清洁的流程。
Service classes are SRP killers. By definition they are an aggregation of operations - which is contrary to SRP. Often single method of the service would require some dependency, that all other methods might not care at all, then with each such method dependencies multiply, it leads to mess. Manager, Service, sometime Repository - these patterns are plain bad from dependencies point of view. In Commands/Queries/Requests world you would have these 3 commands and a query just grouped into a domain/directory. That leads to cleaner, smaller, easier to read and extendable code. Also to cleaner processes.