部分方法是否有害？

Question

在C＃3.0中，Microsoft引入了对partial methods的支持。

你使用它们吗？你能描述一下如何以及为什么？

您是否考虑使用部分方法进行良好的编程实践？

Answer 1

在运行时评估或不使用此类可扩展性的用户可见代码中，部分方法主要用于扩展工具生成代码的行为而无需成本。

因此，他们的使用是明智的，并且在必要时予以鼓励，但对于大多数用户（他们不编写生成代码的工具）来说，这种情况相对不常见。 如果您正在编写这样的工具，那么应该考虑人们可以与您生成的代码流进行交互的位置，以及在实现预期的性能和可用性目标的同时，是否无法通过类似事件的机制轻松处理此类使用。事件本质上是多播的，并且这种结构可能固有地违背API的预期设计。或者，可能需要复杂的返回值或与ref / out参数的交互，最终扩展可能是复杂/易碎的，尽管它具有实用性，因此只有部分类实现者可以处于充分处理这一点的位置。所有这些原因都有其利基，如果不是常见的，部分方法可以有效地解决它们。

实现部分方法的

消费者应该使用它们作为工具生成的代码指示（如果提供了扩展点并且您需要它，请使用它）。 为避免这样做，因为人们认为该功能令人困惑，因此语言和API的使用率很低，因为这显然是预期的扩展点。

Answer 2

与部分类本身一样，它们仅与工具（设计者）生成的代码结合使用。在那里，他们提供了简单，轻量级的活动替代品。

Answer 3

我有机会在我写的类库上使用部分方法。可以使用定义的常量将库编译成几个不同版本中的一个，这些常量可以编译或编译出各种函数块。

但是对于所有选项组合，使用#if / #endif乱丢代码，与Compact Framework以及桌面框架交叉，导致一些令人困惑的东西。

我使用了部分方法来简化这一部分 - 作为一种不可见或隐含的#if /＃endif。这与它在LINQ中的使用方式类似，据我所知。

另一方面，我不会在运行时添加这些方法，就像LINQ那样。而不是linq模型，其中有可分离的程序集，并且在组合时你获得额外的功能，在我的类lib中，为每个选项组合构建了一个DLL。这是为了使部署和使用更容易。

Answer 4

部分类使C＃和VB的工作更像C和C ++，您可以根据需要将实现类的代码分散到不同的文件中。他们的主要目的是为WPF之类的东西提供干净的视觉设计师支持。我认为这对于部分课程很有用。

我看到的另一个用途是将大型源文件拆分为逻辑部分。例如，class BigForm可能跨越BigForm-BillingInfo.cs，BigForm-ShippingInfo.cs和BigForm-LineItems.cs文件。这通常是对部分类的不良使用，因为重构为多个类或控件是更好的OOP设计（可重用性等）。

Answer 5

部分类是一个非常有用的功能，例如，当您有客户端和服务器时，它们都需要共享业务对象持久性的数据类型。你有你的常规类服务器端，你在客户端公开你的web服务，如果你想装饰客户端的东西，非常漂亮，你可以制作你的类的部分版本（客户端你有一个代码生成的版本的服务器版本通过代理生成等。）。

我只是想说这个例子，因为我对部分功能进行了扩展使用，现在，正在开发一个Silverlight项目，持久化断开的对象：）

//很抱歉没有注意到问题明确提到了方法。部分方法对于在事件处理程序中编织代码功能非常有用，在某些情况下自动生成。

Answer 6

微软的编程文化一直倾向于采用更宽松的“胶带”方式。这至少可以追溯到Quick BASIC vs. Turbo Pascal战争。 Microsoft语言允许快捷方式。以代表为例：委托基本上是一个你忘记设计的界面。部分方法更加相同。

你问题的标题是指Edsger Dijkstra给CACM的臭名昭着的信，这很贴切。 Dijkstra信是结构化编程战争的官方起始枪。就个人而言，我不认为你会在所有情况下提倡结构化或非结构化的道路，从而找到智慧。

我一直认为这种冲突是工程与计算机科学观点差异的产物。 Eary微软程序员整天都在编写裸机。在编写了足够的汇编程序之后，结构化编程的要求似乎有点愚蠢。

权衡归结为：您是否希望有足够的绳索悬挂自己，或者您是否希望被迫重写部分架构以满足语言的不灵活性？一个有缺陷的团队可以在任何一个环境中编写好的代码，并且没有普遍的正确答案。

回到手头的问题：我不相信部分方法是一个很好的语言功能，但如果它们是使LINQ工作所必需的，那么它们绝对值得容忍。