单一职责原则和实体类

Question

关于单一职责原则，以及关于过大类的无处不在的警告，这一切如何适用于实体类？就其本质而言，实体难道不应该封装有关一个实体的所有内容吗？这不是他们的“单一责任”吗？

否则，假设您的实体类变得“太大”，如某些人所说，您将如何在不破坏实体应提供的自然封装的情况下实际分解它？如果你有一个 Person 类，只有名字、年龄和最喜欢的食物，那么显然它们都应该是 Person 的属性。但是，如果您需要添加 20 多个类似的属性，例如眼睛颜色、isRightHanded、ReligionOfChoice 等，该怎么办？只是因为他们很多，这是否意味着他们需要被分成不同的班级？为“Properties1To5”和“Properties6To10”设置一个单独的类，然后用它们组成 Person 类，这似乎很愚蠢？

或者直接在 Person 类中保留 100 个属性（理论上可能彼此无关，除了它们属于 Person 的事实）更正确，因为 Person 类的唯一职责是封装关于一个人的一切？

Answer 1

如果您查看一些编码标准文档，您可能会遇到“类不应大于 'x' 方法”的说法。这些“标准”存在信心，但没有多大用处。这个想法是为了阻止开发人员创建 8000 行、单片、一刀切的类。我知道，我以前见过它，这太可怕了。但是，限制“每个类的方法数”，或者在您的示例中，“每个 POCO 的属性数”可能会使事情变得模糊。

确实，以“每个类不超过 30 个方法”为例（例如，什么？），由于 30 个方法的限制，您最终会得到零散的类，这些类纯粹是零散的。这实际上让事情变得更糟。

类应该和它们需要的一样大。这实际上取决于您的应用程序的设计和要求。关于一个人，我真正需要了解什么，以及在我的要求范围内什么是重要的？如果我需要 100 个属性，并且业务规则有一个事实上需要记录这些属性中的每一个 - 并且它们用于报告和/或业务逻辑，那么这是有道理的你的 Person 有 100 个属性。将它们分成块只会混淆数据，混淆代码，让事情变得有点噩梦。

也就是说，有时您可能希望将某些特征拆分到与我们的主 Person POCO 相关的其他类中。您提到宗教是一种属性，也许在业务应用程序中它是必要的。但是，如果您的应用程序的目的是弄清楚人们如何随着时间的推移改变他们的宗教信仰，那么成为Person 的一部分是没有意义的，不是吗？我们现在突然有了一个ReligionInstance POCO，它记录了他们在特定时间点的信念。我相信您可以看到我的目标，因为我确信在其他 100 个属性中 - 根据项目的需要 - 其他人可能会被隔离到他们自己的对象中，因为 这就是逻辑需要。例如，很容易添加地址所需的 7/8 字段。听起来不错，很好听，很简单。 然而，如果这个人移动了，我们就没有他们之前在哪里的记录。突然之间，地址看起来像是一个很好的候选者，可以移动到自己的对象中并链接回该人如果我们关心他们移动了。

当你提到作曲时，我的想法是一样的——因为你想要创建的对象是其他信息的复合。如果我们想象我们存储了一个 Person 并且我们还存储了 1 个或多个 Address POCO。根据业务逻辑，我可能只想要这个人，或者我可能想要他们和他们的地址。

这就是我所说的合成。我们的数据库有我们的Person 和我们的Address，我们有一个名为PersonWithAddresses（例如）的非数据库POCO，它将为我们提供该人的信息及其所有地址。业务规则定义了这些对象，我认为PersonWithAddresses 是一个组合。

现在是这样，哪个存储库处理这个？我们可能有一个PersonRepository 和一个AddressRepository，它们都负责各自的POCO。我们是否也有一个CompositePerson 存储库，使用这两个存储库来构建一个更重量级的 POCO，它包含我们需要的所有信息？我们遵循单一职责模式。我们在需要的时候保持轻量级，没有什么比它应该做的更多。