单一责任原则（SRP）和我的服务类

Question

我有YoutubeVideoService类进行CRUD（创建，读取，更新和删除）操作。在我看来，创建，读取，更新和删除是改变类的四个原因。这个类是否违反了单一责任原则？

如果它违反了，那么我们应该有四个类，如CreateYoutubeVideoService，ReadYoutubeVideoService，UpdateYoutubeVideoService和DeleteYoutubeVideoService。拥有很多课程不是一种矫枉过正吗？

Answer 1

我认为你在课堂上将单一可重复性原则略微提升到极致，而没有考虑到凝聚力。

如果你遵循这条路线，你可以证明有很多只有一两种方法的类，这反过来会增加对天空的依赖数。

我认为SRP的精神是尽可能地简化，但不是更多。

Answer 2

衡量与“单一责任原则”的一致性的一个好方法是考虑改变此类的理由。如果您认为更改的原因不止一个，则可能是违反了SRP。

像这样更改CRUD类的唯一原因是底层数据结构的更改。因此，这尊重了SRP。

另一方面，如果您在该类中进行了其他任何操作（例如，在插入视频之前检查视频长度或类型），则会违反SRP，因为它可以独立于持久性层进行更改。

SRP不是教条，在遵循SOLID原则时，我们始终必须小心，不要引入针头复杂性。根据{{​​3}}，谈到何时应分开两个责任：

  

另一方面，如果应用程序没有以导致两个职责在不同时间更改的方式进行更改，则无需将它们分开。确实，将它们分离会散发出不必要的复杂性。   （...）如果没有症状，则不建议应用SRP（或其他任何原则）。

Answer 3

方法应该多长时间？可以说没有理由拥有超过2行。但在某些情况下，这肯定是矫枉过正的。与SRP相同 - 你必须决定何时足够。 CRUD看起来像一组紧密结合的操作，非常适合单个类，因为它们在相同类型的数据上运行。

Answer 4

服务类别是SRP的杀手ers。根据定义，它们是操作的集合-与SRP相反。通常，服务的单个方法将需要一定的依赖关系，而其他所有方法可能根本不在乎，因此，随着每个这样的方法依赖关系相乘，会导致混乱。经理，服务，有时是存储库-从依赖关系的角度来看，这些模式很糟糕。在“命令/查询/请求”世界中，您需要将这3个命令和一个查询分组到一个域/目录中。这样可以使代码更整洁，更小，更易于阅读和扩展。还有清洁过程。