评估在 C# 中使用扩展方法的成本/收益 => 3.0 [关闭]

在什么情况下（使用场景）您会选择编写扩展而不是对对象进行子类化？

我发现扩展方法的想法“很酷”，显然你可以用它们做“遥远”的事情，就像 Mitsu Furota (MS) 博客文章中的许多例子一样链接文本.

一位私人朋友编写了开源 Componax 库链接文本，那里有一些非凡的设施；但他完全掌控着他的小公司，完全控制着代码指南，每一行代码都“经过他的双手”。

虽然这是我的猜测：我认为/猜测在中型到大型软件团队重新使用扩展的情况下可能会出现其他问题。

查看 MS 的指南链接文本， 你发现 ：

一般来说，你可能会是 更多地调用扩展方法 通常比实现你自己的更重要。 ... 一般来说，我们建议您 谨慎地实现扩展方法 并且仅在必要时才这样做。每当 可能的，必须扩展的客户端代码 现有类型应该这样做 创建一个派生自的新类型 现有类型。了解更多信息， 请参阅继承（C# 编程 指导）。 ...当编译器 遇到方法调用时， 首先在类型中查找匹配项 实例方法。如果没有匹配项 找到后，它将搜索任何 定义的扩展方法 类型，并绑定到第一个 它找到的扩展方法。

还有在女士家链接文本 :

扩展方法没有具体说明 安全漏洞。他们能 切勿用于冒充现有的 类型上的方法，因为所有名称 冲突的解决有利于 定义的实例或静态方法 由类型本身。扩展方法 无法访问任何私有数据 扩展课。

对我来说显而易见的因素包括：

1. 我假设您不会编写扩展，除非您希望它被非常普遍和频繁地使用。另一方面：你不能对子类说同样的话吗？

2. 知道我们可以将它们编译成一个单独的 dll，然后添加编译后的 dll，引用它，然后使用扩展：这很“酷”，但这是否“平衡”了编译器首先必须检查的固有成本如果实例方法是如上所述定义的。或者，在发生“名称冲突”的情况下，使用静态调用方法来确保调用您的扩展而不是实例定义的成本？

扩展的频繁使用会影响运行时性能或内存使用：我不知道。

因此，与子类相比，我很感激您的想法，或者了解您如何/何时使用或不使用扩展。

谢谢，比尔

我对它们的最大用途是扩展封闭的第 3 方 API。

大多数时候，当软件开发人员在 Windows 上提供 API 时，他们会越来越倾向于 .NET 的可扩展性。我喜欢这样做，因为我更喜欢依赖我自己的方法，我可以在将来修改这些方法，并作为他们的 API 的全局入口点，以防他们更改它。

以前，当必须这样做时，我无法继承 API 对象，因为它是密封的或其他什么，我会依赖适配器模式制作我自己的类来包装他们的对象。这是一个实用但相当不优雅的解决方案。扩展方法为您提供了一种向您无法控制的事物添加更多功能的绝妙方式。

许多其他人对它们的最大用途是LINQ!

如果没有提供给 IEnumerable 的扩展方法，LINQ 就不可能实现。

人们之所以喜爱他们，是因为它们使代码更具可读性.

我注意到扩展方法的另一个主要用途（包括我自己）是使代码更具可读性，并使代码看起来好像在做某事属于它应该在的地方。它还摆脱了我多次看到的可怕的“Util”静态神级。什么看起来更好...Util.DecimalToFraction(decimal value); or value.ToFraction();？如果你像我一样，那就是后者。

最后，有些人认为“静态方法”是EVIL!

许多“优秀的程序员”会告诉您应该尽量避免静态方法，尤其是那些使用大量单元测试的静态方法。静态方法在某些情况下很难测试，但它们not evil如果使用得当。而扩展方法ARE静态...它们看起来或行为不像它。这允许您将这些静态方法从类中取出，并放到它们真正应该附加到的对象上。

至于性能..

扩展方法与调用静态方法没有什么不同，将要扩展的对象作为参数传递......因为这就是编译器将其转变为的内容。这样做的好处是你的代码看起来很干净，它可以做你想要的事情，并且编译器会为你处理肮脏的工作。