最佳实践：何时不/使用部分类

Question

我一直在使用partial class修饰符，以便将helper类放在自己的文件中。

今天我们找到了一个新人，他说他工作的最后一个团队不允许使用部分类，因为修改一个单独文件中的辅助类会导致主要的部分类文件失败。随着变化。此外，他们只被允许在主类中放置辅助类作为最后的手段，以便所有内容保持解耦。

你怎么看？使用像这样的部分类有什么问题，还是归结为偏好？

例如，我通常会有这样的事情：

• MainClass.cs
• MainClass.Helper1.cs
• MainClass.Helper2.cs

...

// Inside of MainClass.cs I have code like this:

public abstract partial class MainClass
{
    // ...
}

// Then in the MainClass.Helper1.cs I have:

partial class MainClass
{
   private class Helper1
   {
       // ...
   }
}

Answer 1

部分类主要用于代码生成器的使用，例如设计者 - 但我使用你引用的方法 - 特别是当一个对象实现多个（非平凡的）接口时，我发现它有用的是每个接口实现分解1个文件。我也常常有一个静态方法的文件，它通常与实例方法不同，以保证分离。

Answer 2

我个人认为使用像这样的分类没有任何问题，但这只是我自己的看法。唯一可能看起来像“糟糕的做法”的是将你的类命名为“Helper1”和“Helper2”（但这可能只是一个澄清的例子）。

如果您正在使用这样的部分类，请查看（免费）插件vsCommands（适用于Visual Studio 2008），这样可以轻松地在解决方案资源管理器中对文件进行分组（就像设计器文件一样）编辑项目文件。

Answer 3

简短回答： 如果所有类都是你的代码，那么你真的不需要帮助类，这会使你对partials的需求无效。

答案很长： 我不确定是否有任何说明你的做法明显错误的事情。根据我的经验，如果你有几个不同的文件组成整个班级，你需要有充分的理由这样做，因为：

1. 部分类在某种程度上降低了可读性
2. 如果你的类中有多个辅助类，它可能是设计不佳的症状，我不认为我曾经遇到过被迫为我创建的类编写辅助类的情况。 / LI>

   但是，我认为使用部分类的最佳理由是代码生成，您希望能够在不丢失自定义工作的情况下重新生成文件。

Answer 4

我实际上做了同样的事情。如上所述，在破译部分类时会有轻微的可读性。

解耦是我喜欢这个解决方案的主要原因。私有内部类与其他所有东西的联系要少得多，因为没有别的东西可以看到或使用它（尽管他们可能正在谈论它访问父类私有数据的可能性，这通常是一个坏主意）。 / p>

Answer 5

根据我的经验，noramal类和partial class之间没有区别。如果你的设计需要大型的类或者实现更多的接口，那么就去分部。两者都是一样的。

Answer 6

我不是部分课程的忠实粉丝，也不会自己使用它们。

有一次我发现它们很有用而且可以使用，但是当你想在LINQ to SQL设计器代码中添加一些东西时，除了我发现你是否正在将代码扩展到不同的文件中为此，它可以使阅读和管理变得非常困难。

也许如果您将课程分成许多文件，那么您的课程可能会做很多......只是一个想法：）

Answer 7

我认为如果嵌套类足够大，你觉得需要将它们拆分成自己的文件，那么它们可能不应该是嵌套类。使它们成为与MainClass相同的命名空间的内部成员。

部分类实际上只支持代码生成器并使用它们将程序员编写的代码分解为可管理的块，这是设计不良的一个指标。

请参阅this article，了解一些与部分类无关的热闹示例。

Answer 8

由于上述类似的原因，我通常不会使用部分类。

但是！虽然不常见，但我有时发现广泛的单元测试类（通常是外部类）会导致巨大的单元测试类。将单元测试类拆分为部分类使得它更易于理解和理解。

与从多个接口继承时的分组思想类似，可以对单元测试进行分组以实现功能。

Answer 9

我认为记住你的工具的默认行为是创建一个低级别的耦合非内聚形式是很好的;并持怀疑态度，并覆盖它，除非它对上面列出的某些具体原因有意义。但这不是很好的默认行为。

Answer 10

我大多数时候只使用部分类生成代码，因此我可以将类的行为扩展到需要进行自定义而不包含在代码生成中的独立类中。