oop - 单一职责原则和实体类

Question

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

否则，假设您的实体类变得“太大”，正如某些人可能会说的那样，您如何在不破坏该实体应提供的自然封装的情况下实际分解它？如果你有一个 Person 类，只有名字、年龄和最喜欢的食物，那么显然它们都应该是 Person 的属性。但是，如果您需要添加 20 个以上相似的属性(例如眼睛颜色、isRightHanded、ReligionOfChoice 等)怎么办？就因为人数多，就突然需要分类了？为“Properties1To5”和“Properties6To10”创建一个单独的类，然后用它们组成 Person 类，这似乎很愚蠢？

或者直接将 100 个属性(理论上可以彼此无关，除了它们属于 Person 之外)直接保留在 Person 类中是否更正确，因为 Person 类的唯一职责是封装关于一个人的一切？

Answer 1

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

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

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

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

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

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

现在问题是，哪个存储库处理这个问题？我们可能有一个 PersonRepository 和一个 AddressRepository，两者都负责各自的 POCO。我们是否还可以有一个 CompositePerson 存储库，使用这两个存储库来构建一个更重量级的 POCO，其中包含我们需要的所有信息？我们坚持单一职责模式。当我们需要时，我们会保持轻量级，并且没有什么比它应该做的更多。