我有YoutubeVideoService执行 CRUD（创建、读取、更新和删除）操作的类。在我看来，创建、读取、更新和删除是更改类的四个原因。这个类是否违反了单一职责原则？
如果它违反了，那么我们应该有四个类，如CreateYoutubeVideoService、和。有很多课程不是矫枉过正吗？ReadYoutubeVideoServiceUpdateYoutubeVideoServiceDeleteYoutubeVideoService
问问题
1449 次
4 回答
5
我认为您在课程级别上将单一可重复性原则推向了极端，而没有考虑凝聚力。
如果你遵循这条路线，你可以证明只有一两个方法有很多类是合理的，这反过来会增加对天空的依赖数量。
我认为 SRP 的精神是尽可能地简化，但不是更多。
于 2011-10-10T19:24:43.537 回答
1
衡量单一职责原则一致性的一个好方法是考虑改变这个类有多少理由。如果你能想到不止一个改变的理由，很可能它违反了 SRP。
像这样更改CRUD类的唯一原因是底层数据结构的更改。所以这尊重 SRP。
另一方面，如果您在该类中有任何其他操作（例如，在插入之前检查视频长度或类型），那将违反 SRP，因为它可以独立于持久层而改变。
SRP 不是教条，当遵循SOLID原则时，我们总是要小心不要引入针复杂性。根据鲍勃·马丁的杰作，谈到什么时候应该分开两个责任：
另一方面，如果应用程序没有以导致两种职责在不同时间发生变化的方式发生变化，则无需将它们分开。事实上，将它们分开会散发出不必要的复杂性。(...) 如果没有症状，则应用 SRP（或任何其他原则）是不明智的。
于 2019-06-11T14:21:36.627 回答
1
服务类是 SRP 杀手。根据定义，它们是操作的集合——这与 SRP 相反。通常服务的单个方法需要一些依赖，所有其他方法可能根本不关心，然后随着每个这样的方法依赖成倍增加，它会导致混乱。管理器、服务、有时是存储库——从依赖关系的角度来看，这些模式很糟糕。在命令/查询/请求世界中，您将拥有这 3 个命令和一个查询，它们只是分组到一个域/目录中。这导致代码更简洁、更小、更易于阅读和可扩展。也为了更清洁的过程。
于 2020-09-09T18:00:58.317 回答
0
方法应该多长时间？可以说没有理由超过 2 行。但这在某些情况下肯定是矫枉过正。与 SRP 相同 - 您必须决定何时足够。CRUD 看起来像是一组非常适合单个类的内聚操作，因为它们对相同类型的数据进行操作。
于 2011-10-10T19:22:43.990 回答