部分元素与主要的 OO 编程概念相比如何？它们是主要的还是备用的？

Posted 2023-03-08

【中文标题】部分元素与主要的 OO 编程概念相比如何？它们是主要的还是备用的？

【英文标题】：How do partial elements compare to main OO programming concepts and are they primary or fall-back?

【发布时间】：2011-11-20 11:20:55

【问题描述】：

部分类对我来说就像继承。有时我发现自己想知道我应该派生或部分化或进行扩展的天气。这三个都扩展了一个类型的行为。

帮助我在等效机制之间做出决定的一些事情是：

它利用了 OO 编程的哪些元素？

它被认为是首选还是后备？

我在查看像继承这样的部分类时是否正确？它们的使用是否应仅限于某些特殊情况？

如果有人能给我一些历史背景，那将是一个奖励——谁想出来的？与扩展方法促进 LINQ 的方式相比，它们是他们最初解决的特定问题吗？

【问题讨论】：

4 个答案来自大约 700K 点 - 非常感谢

在 C++ 中，从来没有要求在一个文件中定义一个类的所有方法。

相关/复制：Why use partial classes?

我知道 - 即使在 C# 10 年后，我的 C++ 背景却经常让我走在低于最佳实践的道路上

【参考方案1】：

它与 OO 或任何其他范例无关。

它是一个后备方案，它是为了支持工具和设计器而引入的。 例如MyForm.Designer.cs、MyDataset.Designer.cs等

如果代码都是你的（没有工具或生成器），你就不想使用部分类。

【参考方案2】：

部分类的一个问题是它们使继承复杂化。如果您想让您的类从另一个类继承，您必须将所有类声明（每个部分和公共）更改为继承。

我建议不要在 WinForms 之外使用它们。如果您需要在不继承的情况下扩展类，请使用扩展方法，它们会更干净。

【讨论】：

我正在使用由 xsd.exe 生成的类，因此它们已经是部分的

WinForms 有点受限。 DataAnnotations 和 EF 也需要部分类。

【参考方案3】：

我在查看像继承这样的部分类时是否正确？它们的使用是否应仅限于某些特殊情况？

部分类只是一种组织方法。它们与继承无关，因为一旦编译，它们就会完全“消失”。

这只是在多个文件之间拆分代码的一种方式。

话虽如此，我个人只建议使用分部类来扩展由工具生成的类，例如 UI 设计器、服务合同、ORM 等。将分部类用于您自己的代码往往会导致类太大，应该将其重构为单独的、较小的类，每个类都有一个目的。

【参考方案4】：

Partials 是编译器特性，与 OO 无关。

在 C# 中，它们只是允许您将一个类拆分为多个单独的文件。

这是一种允许生成的代码与手工编写的代码一起使用而不会影响另一个的方法（我知道这是功能的简化）。

我建议reading about the feature。

【参考方案5】：

部分类型不是继承，简单明了。

部分类型只是一种将单一类型的代码分离成多个源文件的方法——通常这样一些可以由设计人员生成，而另一些则不能。仅此而已。

他们解决的具体问题是设计器代码和手动代码之间的分离——避免“不要碰文件的这一部分！” .NET 1.1 中存在 WinForms 代码的问题。

请注意，.NET 2+ 和 WPF 中的 WinForms 的模型略有不同 - 在 WPF/Silverlight 中，“额外源文件”甚至不存在以供签入 - 它是作为构建过程的一部分从 XAML 生成的，就在类型本身被编译之前。 （您仍然可以在obj 输出目录中找到生成的代码，通常称为SomeType.g.cs。）