我想知道是否有人能给我一个概述,为什么我要使用它们,在这个过程中我能获得什么好处。


当前回答

我注意到两个用法,我在答案中没有明确找到。

分类项目分组

一些开发人员使用注释来分离类的不同“部分”。例如,一个团队可能使用以下约定:

public class MyClass{  
  //Member variables
  //Constructors
  //Properties
  //Methods
}

对于分部类,我们可以更进一步,将部分分割到单独的文件中。按照惯例,团队可以在每个文件后面加上与之对应的部分。所以在上面我们会有这样的东西:MyClassMembers.cs, MyClassConstructors.cs, MyClassProperties.cs, MyClassMethods.cs。

正如其他答案所暗示的那样,是否值得将班级分开可能取决于在这种情况下班级的规模。如果它很小,那么把所有东西都放在一个大师班可能会更容易。但是,如果这些部分中的任何一部分太大,它的内容可以移动到一个单独的分部类中,以保持主类的整洁。在这种情况下,惯例可能是在节标题后留下类似“See partial class”的注释,例如:

//Methods - See partial class

管理使用语句/命名空间的范围

这种情况可能很少发生,但是来自您想要使用的库的两个函数之间可能会发生名称空间冲突。在单个类中,最多只能为其中一个使用using子句。对于另一种,您需要一个完全限定的名称或别名。对于部分类,由于每个名称空间& using语句列表都不同,因此可以将两组函数分离到两个单独的文件中。

其他回答

一个很好的用法是将生成的代码与属于同一类的手写代码分离。

例如,由于LINQ to SQL使用部分类,您可以编写自己的某些功能片段的实现(如多对多关系),并且当您重新生成代码时,这些自定义代码片段不会被覆盖。

WinForms代码也是如此。所有设计器生成的代码都放在一个文件中,您通常不会接触这个文件。手写的代码放到另一个文件中。这样,当您在设计器中更改某些内容时,您所做的更改不会被影响。

的确,Partial Class用于自动代码生成,其中一个用途是维护一个可能有上千行代码的大型类文件。你永远不知道你的类最终会有1万行,你不想用不同的名字创建一个新类。

public partial class Product
{
    // 50 business logic embedded in methods and properties..
}

public partial class Product
{
    // another 50 business logic embedded in methods and properties..
}
//finally compile with product.class file.

另一个可能的用途是多个开发人员可以使用同一个类,因为它们存储在不同的地方。人们可能会笑,但你永远不知道有时候情况会很棘手。

Product1.cs

public partial class Product
{
    //you are writing the business logic for fast moving product
}

Product2.cs

public partial class Product
{
    // Another developer writing some business logic...
}

希望这是有意义的!

我发现令人不安的是,“凝聚力”这个词在这些帖子中没有出现(直到现在)。 我也很不安,有人认为启用或鼓励大型类和方法在某种程度上是件好事。 如果你试图理解和维护代码基础的“部分”,那就糟透了。

部分类最近帮助了源代码控制,多个开发人员在一个文件中添加新方法,并将其添加到文件的同一部分(由Resharper自动化)。

这些推入git会导致合并冲突。我发现没有办法告诉合并工具把新方法作为一个完整的代码块。

在这方面,部分类允许开发人员坚持他们文件的一个版本,并且我们可以稍后手工将它们合并回去。

的例子,

cs—保存字段、构造函数等 MainClass1.cs—开发人员实现时的新代码 cs -是另一个用于新代码的开发人员类。

作为预编译器指令的替代方案。

如果您使用预编译器指令(即# If DEBUG),那么您最终会看到一些看起来粗糙的代码与实际的Release代码混合在一起。

你可以创建一个单独的分部类来包含这些代码,或者将整个分部类包装在一个指令中,或者省略该代码文件,使其不被发送给编译器(实际上是做同样的事情)。