单一责任原则：班级或方法级别

Question

我在理解单一责任原则方面存在问题。应该在班级或方法级别应用SRP。 假设我有学生班，我需要创建学生，更新学生和删除学生。  如果我创建一个具有这三个操作方法的服务类，这会破坏SRP原则。

Answer 1

我说你有一个服务类负责对Student类型的对象进行CRUD操作。我根本没有看到这种设计违反SRP 引自http://www.developerfusion.com/article/137636/taking-the-single-responsibility-principle-seriously/

  

同一类（甚至不同类）的两种方法应该关注不同的方面。但是，同一类中的两种方法，例如，存储库，可能都必须关注相同的更高级别的责任，例如：持久性。

我将CRUD视为单个上下文中的众所周知的操作，除非您有一些与之相关的业务。例如，您可能希望允许某些类只能读取数据并拒绝它们对其进行任何更改。那时你可以使用另一个SOLID原则Interface segregation 您可以定义仅定义了在这些类中使用的read方法的接口。或者如果它有意义（例如性能），创建一个单独的具体类，它只实现读操作。

Answer 2

SRP同时处于课堂和方法水平。所以，如果你在谈论学生班，那么在这种情况下只有责任对学生实体做CRUD。同时当你谈论方法时，你不应该有一个InsertStudent方法，并根据ID执行更新和插入。如果你有插入的InsertStudent和更新它的UpdateStudent，则会中断SRP.But

Answer 3

不要批评我，因为我相信原理，但是如果您不使用“ and”就可以总结功能，那么请不要遵循它说的建议。有了这种逻辑，您仍然可以拥有一个庞大的单一文件应用程序，无需使用“ and”即可说出它的职责。 Web浏览器是一个复杂的软件，但是您仍然可以在一个简短的声明中对其进行描述。这是完全有意义的，因为事物就像金字塔一样，无论零件是否被分割，您都应该始终能够描述顶层。

这正是我们每天使用功能所做的事情。您选择了一个非常简单的函数名称，该名称隐藏了套接字的“ connect”之类的复杂性。从这个角度来看，您实际上并不知道之后是否将其拆分。这可能是一个巨大的功能。

恐怕它仍然是主观的。您不想基于用语言总结功能的能力来判断设计。总是应该这样，因为这是选择方法名称的方式，我们都知道命名很困难。

我的建议是将SOLID主体视为一个整体而不是单个规则，并围绕您认为要更改的内容和不太可能更改的内容建立隔离。显而易见的候选人是依赖性。它仍然是主观的，没有办法解决，但可以为您提供帮助。

我个人有时很难做到，但这是值得的。我不知道您是否知道Ecto这是一个万能药项目，但是当我发现它时，我有一个“Voilà”的时刻。在很多方面都不是完美的，但是与Ecto和关注点分离有关的事情通常是一开始似乎很多间接的事情，但是随后将事情分离是有意义的。在最幸福的时刻，感觉就像是您可以信任的许多小部件。

过去，我认为模型应该非常聪明，以至于它知道如何将自身保存到数据库，如何进行自我验证以及如何进行各种操作。但是现实是，一旦您决定要使用其他数据库，或者根据情况等进行不同的验证，那么就很难摆脱困境了。我敢肯定，有些开发人员从来没有这样的感觉，然后就可以了。但是对我来说，这是一个挑战。

很多简单的情况，但是您希望每个班级的知识尽可能少。您不希望Mail类知道“紧急”的css颜色是“＃FF0000”。然后更难的东西，例如有时您甚至不希望它知道它是“紧急的”，因为它取决于用例的事实。

这不容易。在您的特定情况下，例如，我个人不会打扰混合“ create”和“ delete”，但是我会确保与数据库进行交互是它所做的一切。它不知道事物是否有效，是否具有回调等。几乎是存储库模式。同样，Ecto是一个很好的例子，或者至少我发现它很有帮助。