2

当我第一次了解扩展方法时，我读到了这个：

一般来说，我们建议您谨慎地实施扩展方法，并且仅在必要时才实施。只要有可能，必须扩展现有类型的客户端代码应该通过创建从现有类型派生的新类型来实现。

然而，我多次看到在各种生产代码库中非常自由地使用扩展方法。

诚然，我的经验不能代表大多数人，但我想知道指导方针是否发生了变化，替代的设计理念，或者我是否碰巧看到了足够多的代码忽略了指导方针让我这么想？

注意：我并不是想引发一场辩论（这会立即导致这个问题结束） - 老实说，我一直在想这个问题，并且觉得我获得答案的最佳机会就在这里。

4

4 回答 4

2

我认为所有这些亮点都是理论与实践之间的通常差异。理论上我们应该谨慎使用它们，但实际上我们不会。理论上，我们应该做很多我们在实践中不做的事情，在一般的生活中，不仅仅是编程。

于 2012-05-23T16:33:24.050 回答
2

多态性不适用于扩展方法，因为它们在编译时绑定。

ParentClass parentClass = new ParentClass();
ParentClass derivedClass = new DerivedClass();

如果这两个类都有一个名为 ExtensionMethod() 的扩展方法（我肯定看到过试图模仿虚拟/覆盖方法的扩展方法），那么这两个调用都会调用父类的扩展方法：

 parentClass.ExtensionMethod();
 derivedClass.ExtensionMethod();

为了实际使用派生扩展方法，您必须调用：

 ((DerivedClass)derivedClass).ExtensionMethod();
于 2012-05-23T17:35:27.220 回答
1

扩展类是一个好方法，但它通常不适用于使用第三方库的代码（与教育/示例代码不同，这是生产代码的常见情况）。因此，如果有意义，请派生新类，但当它们使代码更具可读性时，请随意使用扩展方法。

有很多扩展方法的原因有很多：

  • 通常你不能扩展一个类来添加可以使你的产品代码更具可读性的方法。即像String这样的值类型或像Stream这样的层次结构中的一些基类。
  • 扩展方法是在不污染接口的情况下向接口添加方法的有价值的方法。LINQ 是一个很好的例子，它如何生成更具可读性的代码。
  • 一些框架建议在特定情况下使用扩展方法。即，对于 MVC，建议向 HtmlHelper 添加扩展。
于 2012-05-23T17:03:52.483 回答
1

我认为使用扩展方法有利有弊。

优点： 扩展方法可以看作访问者模式（GoF）。因此，它利用了模式，即在不修改代码的情况下，我们可以扩展一些功能。

缺点：尽管有优势，但为什么 MSDN 告诉我谨慎使用扩展方法是，IMO，扩展方法在某些时候会引起问题。首先，如果扩展方法的对象与扩展有不同的命名空间，我们应该知道它在哪里。这导致有时我们无法使用扩展中的一些重要功能。此外，我看到了很多滥用扩展的代码。由于扩展是基于Type的，所以有时该类型的对象确实不需要扩展，但是在编码时，我们应该看到很多扩展方法。

[更新]

IMO，关于扩展方法的滥用

  1. 对扩展方法使用如此通用的类型，例如 object：如果有很多具有对象类型的扩展方法，并且该扩展只关注少数类型，那会让我们烦恼，因为每个对象都与方法链接。

  2. 与点运算符或误解的链接断开：让我举个例子。有如下代码，我们应该依次调用 Read 和 Write 方法。但是，我们可以以相反的顺序调用这些方法。

    public static string Read(this string message)
{
    //do something
    return message;
}

public static string Write(this string message)
{
    //do something
    return message;
}

public static void Method()
{
    "message".Read().Write();
    "message".Write().Read(); // this is problem!
}
于 2012-05-23T17:17:12.990 回答