单一责任与封装

Question

我想更多地了解单一责任。如果我尝试代表可以添加，删除，更新，检索的客户，那么过去我的客户类将具有所有的add，remove，update和get方法。这有助于将现实世界中客户的行为归为一类。我只负责将客户类别分为AddCustomer类，删除客户类别，更新客户类别和获取客户类别，甚至获取所有客户类别？

Answer 1

在您描述的场景中，您不需要将您的Customer类分为多个“添加/更新/删除客户”类-实际上，这几乎肯定会使您的系统更难以理解。

顺便说一句，我可能是错的，听起来您正在使用Active Record模式。这种模式本身并没有什么问题，但是它违反了SRP，并且不是可测试性最高的模式，因此我倾向于建议您采用其他方法。

单一责任原则

SRP指出，一类应该只有一个更改理由。但是，如果您考虑当前拥有的东西，那么您的Customer班级已经承担了两个责任，因此已经有两个可能的改变理由

• 在您要实现的任何应用程序域中表示客户的数据和行为
• 保留自己的数据（即所有CRUD操作）。

因此，如果基础数据库发生更改，则需要更新处理持久性的Customer类方法，并且如果Customer的必需行为发生更改，则必须更新Customer类以实现新的行为。

它如何帮助

当您遇到这种情况时，您的Customer类总是有机会以混合代码结束，这些代码将业务逻辑和数据库持久性逻辑纠缠在一起，形成高度耦合的混乱局面，以至于以后您发现很难对一个代码进行更改方面不会造成其他问题。我去过那里，很不好玩，所以请记住这一点；这实际上就是SRP的全部目的-避免出现经典的“ 大泥巴 ”情况。

从这往哪儿走

• 如果您真的想在SOLID *中使用“ S”，那么我建议从类似Repository模式的东西开始，以处理Customer类与数据库之间的实际持久性（Repository您创建的类当然会遵循SRP，因为它仅与数据库的CRUD有关，并且不包含与之相关的任何“业务逻辑”Customer
• 一旦熟悉了这种方法，就可以继续使用诸如Command模式之类的东西，这里是一个很好的例子，您可以在这里阅读有关Query模式的信息（您将需要两者）。但是，一个不错的简单存储库模式也没有错。

*这可能不是绝对可以证明的东西，但是我个人发现，遵循SOLID原则的代码往往是非常可测试的，非常易于理解和更改的，而且非常健壮。再说一遍，YMMV就是我！