使用扩展方法来增强可读性

Question

除了增强可读性之外，使用扩展方法的一般思考是什么？

如果不使用扩展方法，我们可能会使用方法

IEnumerable<DependencyObject> GetDescendents(DependencyObject root) {}

可以用

调用

var descendents = GetDescendents(someControl);

或

foreach (var descendent in GetDescendents(someControl)) {}

虽然这没有什么问题，但我发现instance.method（）表示法更具可读性，所以我可以考虑使用此签名将其作为扩展方法

public IEnumerable<DependencyObject> GetDescendents(this DependencyObject root) {}

允许用

调用它

var descendents = someControl.GetDescendents();

或

foreach (var descendent in someControl.GetDescendents()) {}

所以我的问题是你认为这是合理的还是滥用扩展方法。如果仅仅是以不同的方式宣布功能，我会毫不犹豫;但是使用扩展方法要求它在不同的静态类中编码这一事实让我想知道它是否值得付出努力。我上面使用的示例是一个相当通用的示例，并且可能具有作为将在几个地方使用的扩展方法的优点，但通常情况并非如此，并且我将在同一文件中编写包含扩展名的静态类。使用它的单个类。

Answer 1

我认为扩展方法的最大优点是可发现性。如果某人不知道他们的某个团队成员在某个实用程序类中创建了一个GetDescendents方法，他们就永远不会使用它。但是，如果该方法开始出现在Intellisense或对象浏览器中，那么他们就有可能偶然发现它。如果您开始更广泛地使用扩展方法，人们将开始使用我提到的工具来寻找增值的扩展。

Answer 2

大多数（如果不是全部）扩展方法在某种程度上属于这个类别，因为它们不能在类的内部操作而不是静态函数。无论如何，任何扩展方法都可以在静态类中重写，并使用一个额外的参数来表示对象（可以说，这正是扩展方法无论如何）。

对我而言，这完全是一个风格问题：在你提供的例子中，我可能会跳转到扩展方法。我认为这里的重要问题是，如果我要重新实现这个类，那么这个函数是否是我作为课程的一部分编写的，并且它是否有意义？如果是，那就去吧它，如果没有，那么考虑一个不同的解决方案。

Answer 3

仅存在扩展方法以提高可读性 - 它只是一种语法快捷方式，允许您通过在第一个参数上指定this关键字，允许您在相关对象实例上调用方法。所以我认为这是完全合理的。