c# - 对于具有相似但不一致的构造函数的众多类，最有效的设计是什么？

Question

我正在使用一个类库，首先，它具有庞大 构造函数，传递了十五或二十个参数。大约有二十个这样的类(class)，他们有相似但不完全相同的论点。在某些情况下，参数十二被省略，在其他情况下，它被指定但不是必需的...

我正在考虑将这些参数组合到对象中，因为其中许多参数彼此相关，例如，将 FirstName、LastName 和 Email Address 组合到一个 Person 对象中。但这似乎导致了几个怪物类，因此对象的任何使用都不会使用所有参数，而且大多数使用只会使用少数几个。

现在所有的验证逻辑都在所有的构造函数中......如果我能解决将构造函数很好地链接到继承链中的问题，那么我就可以创建一个抽象的 Validate() 方法，每个类都可以覆盖它, 并简化设计。我检查了 Refactoring to Patterns，但我没有看到任何似乎与这个问题直接相关的内容。

注意:这不是 this 的骗局- 我说的是相似的构造函数，而不是相似的对象。我已经有了抽象基类。

Answer 1

I'm thinking of composing these arguments into objects because many of them are related to each other

这对我来说是一个很好的步骤。

But this seems to lead to a couple of monster classes

我根本不明白为什么它们需要成为“怪物”类——你可以将它们保留为简单的 DTO 类，尽管你可能想要提供一些验证，如果指定了电子邮件地址，它确实 < em>是一个有效的电子邮件地址等。

whereby NO use of the object ever uses ALL of the arguments

好吧，对象的使用永远不会使用所有的属性。没关系 - 例如，DateTime 很少使用每个属性。

在构造 Person 时，您不必指定所有值 - 计算出哪些是所有用途真正需要的，并将它们放入构造函数中... 然后为参数使用可选参数，或者只使用属性使 Person 类型可变。所以你可以:

Person person = new Person("Jon", "Skeet", // Required parameters
                           email: "skeet@pobox.com"); // Optional

或者:

Person person = new Person("Jon", "Skeet") { Email = "skeet@pobox.com" };

我个人喜欢第一种方法，因为它意味着您的对象可以是不可变的，但这取决于您对可选参数的看法。

无论哪种方式，您的其他类现在只需要采用这些更大的 blob(例如，两个 Person 引用和一个 Location 引用，而不是 12 个不同的引用)。他们可以假设更大的 blob 中的所有 required 值都已经填充(因为它们将在构造函数中验证)，然后他们可以只检查它们碰巧需要的任何可选值是否也已填充填写。