“谨慎使用扩展方法”背后的动机是什么？

Question

我发现它们是扩展现有类的非常自然的方式，特别是当您只需要将某些功能“点焊”到现有类上时。

微软表示，“一般来说，我们建议您谨慎地实现扩展方法，并且仅在必要时才实现。”然而，扩展方法构成了 Linq 的基础；事实上，Linq 是创建扩展方法的原因。

是否存在特定的设计标准，优先使用扩展方法而不是继承或组合？他们在什么标准下被劝阻？

Answer 1

我们向 C# MVP 展示了提议的新语言功能（至少是那些有一定机会面世的功能）以获得早期反馈。我们经常收到的关于许多功能的一些反馈是“嗯，我会根据该功能的设计原则明智地使用该功能，但是我的傻瓜同事会对这个东西发疯，写出大量无法维护、无法理解的代码，我将在接下来的十年里陷入调试困境，所以尽管我想要它，但请永远不要实现这个功能！”

虽然为了喜剧效果我有些夸张，但这是我们非常认真对待的事情；我们希望新功能的设计能够鼓励它们的使用，但阻止它们的滥用。

我们担心扩展方法会被用来，例如，不加区别地任意扩展“对象”，从而创建松散类型的大球泥浆很难理解、调试和维护。

我个人特别关心您在“流畅”编程中看到的“可爱”扩展方法。像呸克之类的东西

6.Times(x=>Print("hello"));

。 “for”循环在 C# 中是普遍可以理解和惯用的； 别表现得可爱。

Answer 2

问题是扩展方法不一定清晰。

当您在代码中看到类似的内容时：

 myObject.Foo();

自然的本能是 Foo() 是在 myObject 类或 myObject 类的父类上定义的方法。

对于扩展方法，情况并非如此。该方法几乎可以在任何地方针对任何类型定义（您可以在 System.Object 上定义扩展方法，尽管这是一个坏主意......）。这确实增加了代码的维护成本，因为它降低了可发现性。

任何时候添加不明显的代码，或者甚至降低实现的“明显性”，都会在长期可维护性方面产生成本。

Answer 3

过度使用扩展方法是不好的，就像过度使用重载运算符不好一样。让我解释一下。

我们先看一下运算符重载的例子。当你看到代码时：

var result = myFoo + myBar;

你会希望 myFoo 和 myBar 是数字类型，并且 operator + 正在执行加法。这是合乎逻辑的、直观的、容易理解的。但是，一旦运算符重载出现，您就无法再确定 myFoo + myBar 实际上在做什么 - + 运算符可能会被重载为意味着任何。您不能只阅读代码并弄清楚发生了什么，而不必阅读表达式中涉及的类型的所有底层代码。现在，operator + 已经对 String 或 DateTime 等类型进行了重载 - 然而，对于加法有一个直观的解释em> 表示在这些情况下。更重要的是，在这些常见情况下，它为代码增加了很多表达能力。因此，潜在的混乱是值得的。

那么这一切与扩展方法有什么关系？嗯，扩展方法引入了类似的情况。如果没有扩展方法，当您看到：

var result = myFoo.DoSomething();

您可以假设 DoSomething() 是 myFoo 的方法或其基类之一。这很简单，易于理解，甚至直观。但是使用扩展方法，DoSomething()可以在任何地方定义 - 更糟糕的是，定义取决于代码文件中的 using 语句集并将可能的许多类引入其中，其中任何一个类都可以托管 DoSomething() 的实现。

请不要误解我的意思。运算符重载和扩展方法都是有用且强大的语言功能。但请记住 - 能力越大，责任越大。当这些功能提高实现的清晰度或能力时，您应该使用它们。如果你开始不加区别地使用它们，它们将会给你想要创建的东西增加混乱、复杂性，甚至可能的缺陷。

Answer 4

我遵循扩展方法和辅助类的非常简单的规则。

每当我有一个可以归入静态帮助器类的方法时，我都会在一般范围内权衡它的有用性，我真的希望共享该方法吗？含义是否清晰并且对其他人有用？

如果我对这个问题的回答是肯定的，我将把它创建为一个扩展方法。我有一个共享库，其中包含 1 个命名空间中的所有扩展方法，每个类文件定义为 TypeNameExtension，因此该类内部的期望内容变得非常清楚，以便您可以轻松找到代码。

如果我质疑是否需要将辅助方法作为全局可访问的用法，我将将该方法声明为私有静态并将其保留在所属类中。

Answer 5

当 Borland 发明它们（Delphi Class Helpers）时，指导方针已经是：“应该只在特殊情况下使用”。

它们已经变得更加被接受（作为 LINQ 的一部分），但它们仍然是一种奇怪的添加功能的方式。我认为里德对原因有一个很好的答案。

Answer 6

我有一个不断增长的扩展方法库，这些方法对 BCL 类进行操作，以简化乍一看令人困惑的常见问题。坦率地说，我认为扩展方法使事情更具可读性。例如，使用 if 语句测试一个数字是否在两个数字之间：

if (x <= right && x >= left )
{
   // Do Something
}

如果 right 意外小于 left 怎么办？那到底有什么作用呢？当变量简单地像x和left时，那么它很容易理解。但如果它们是长类的属性怎么办？ if 语句可能会变得相当大，这会混淆您想要做的相当简单的事情。

所以我写了这样：

public static bool Between<T>(this T test, T minValue, T maxValue)
    where T : IComparable<T>
{
    // If minValue is greater than maxValue, simply reverse the comparision.
    if (minValue.CompareTo(maxValue) == 1)
        return (test.CompareTo(maxValue) >= 0 && test.CompareTo(minValue) <= 0);
    else
        return (test.CompareTo(minValue) >= 0 && test.CompareTo(maxValue) <= 0);
}

现在我可以将 if 语句改进为：

if (x.Between(left, right))
{
   // Do Something
}

这是“非凡”吗？我不这么认为......但我确实认为这是可读性的显着改进，并且它允许对测试输入进行一些额外的安全检查。

我认为微软在这里想要避免的危险是人们编写了大量的扩展方法来重新定义 Equals 和 ToString。

Answer 7

扩展方法可以被认为是面向方面的。我相信微软是在说，如果你有源代码，你应该改变原始的类。它与清晰度和易于维护有关。需要扩展方法的原因是它们扩展现有对象的功能。就 LINQ 而言，如果您深入研究它的工作原理，就会发现可以使用各种无法提前知道的类型来创建对象。使用扩展方法可以添加一些行为。

例如，扩展 .NET 框架对象是有意义的，因为您没有源代码，但可能需要向对象添加一些行为。扩展字符串、DateTime 和 FrameworkElement 类是可以接受的。为跨应用程序边界的类创建扩展方法也是可以接受的。比如说，如果您想共享 DTO 类并具有某些特定的 UI 行为，则仅在 UI 中创建该扩展方法。

对于动态语言，范例是不同的，但我相信您正在谈论 C# 和 VB.net。