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

我已经使用分部类修饰符一段时间了，以便将助手类放在它们自己的文件中

今天我们有一个新的家伙，他说他工作过的最后一个团队不允许使用分部类，因为修改单独文件中的帮助器类会导致主分部类文件与更改不一致。此外，他们只允许在主类中放置一个helper类作为最后的手段，这样一切都保持解耦

你觉得怎么样？像这样使用分部类有什么问题吗？还是归结为偏好

例如，我通常有这样的东西：

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

---

我不太喜欢局部类，我自己也不使用它们

有一次我确实发现它们很有用，而且可以使用，那就是当您想向LINQ to SQL设计器代码中添加一些东西时，但是除此之外，我发现如果您只是为了它而将代码分散到不同的文件中，这会使读和管理变得非常困难

---

也许如果你的类被分割成许多文件，也许你的类正在做很多。。。只是想一想：）

就个人而言，我看不出这样使用分部类有什么错，但这只是我自己的观点。唯一看起来像“坏习惯”的是将类命名为“Helper1”和“Helper2”（但这可能只是一个澄清的示例）

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

简短回答： 如果所有的类都是您的代码，那么您并不真正需要helper类，这使得您对partials的需求无效

长答覆： 我不确定是否有任何东西表明你的做法是明显错误的。根据我的经验，如果您有几个不同的文件组成整个类，那么您确实需要一个很好的理由来这样做，因为：

部分类在某种程度上降低了可读性

如果您的类中有多个helper类，这可能是设计不佳的症状，我想我从未遇到过被迫为我创建的类编写helper类的情况

---

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

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

分部类的存在实际上只是为了支持代码生成器，使用它们将程序员编写的代码分解成可管理的块，这是设计糟糕的一个标志

---

请参阅一个有趣的例子，说明如何处理分部类。

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

我实际上也做了同样的事情。如前所述，破译部分类会对可读性产生轻微影响

---

解耦是我喜欢这个解决方案的主要原因。私有内部类与其他所有对象的耦合程度要低得多，因为没有其他对象可以看到或使用它（尽管他们可能在谈论它访问父类的私有数据的可能性，这通常是个坏主意）.

我认为最好记住，您的工具的默认行为是创建低级形式的耦合，而不是内聚；并以怀疑的态度看待它，并覆盖它，除非出于上面列出的某些特定原因，它是有意义的。但这不是好的默认行为。

大多数时候，我只在代码生成时使用分部类，因此我可以在需要一些自定义且不包含在代码生成中的分离类上扩展类的行为

根据我的经验，noramal类和partial类之间没有区别。如果您的设计需要较大的类结构或实现更多的接口，那么选择partial类。不管怎样，两者都是一样的

出于上述类似原因，我通常从不使用分部类

但是！虽然不频繁，但我有时发现广泛的单元测试一个类（通常是外部类）会导致巨大的单元测试类。将单元测试类拆分为部分类使其看起来更容易理解

---

与从多个接口继承时的分组思想类似，单元测试可以为函数分组。

谢谢，我正在寻找这样的插件。我写了一个宏来完成它。你从来都不需要助手类，真的吗？这让我感到惊讶，因为我在框架中看到太多的类本身都有助手类，比如私有枚举器和私有列表（Dictionary..KeyCollection，Dictionary..ValueCollection等等）。。。Enumerable中嵌套了大约30个助手类。（三十！！）所以我猜你会说这可能是一个糟糕的设计？“在不丢失自定义工作的情况下重新生成文件”绝对是创建分部类的最好理由，如此方便，如此有用。好吧，我不是说帮助器类是糟糕的设计。如果我拥有主类，我就不使用帮助器类。我将“helper”功能构建到主类中。当我不拥有主类（例如框架/第三方类）时，我确实使用了helper类。我想我不知道类的大小与嵌套与否有什么关系

// 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
   {
       // ...
   }
}