C# 什么时候应该避免扩展方法？

在你开始给我指出重复的方法之前，我已经阅读了几乎所有关于扩展方法的文章。我只是想扮演魔鬼的倡导者一分钟来考虑我的工作意见的替代。

最近我在做一个项目，需要一个方法作为接口的基础。所以我建议我们写一个扩展方法，结果被否决了。说它增加了复杂性和调试难度

当然，我争论了一下，然后继续寻找所有精彩的帖子，这些帖子展示了为什么要使用扩展方法的许多原因。不要忘记很多.net框架都使用它们。我们最终没有使用它，因为我被球队否决了

但后来它让我思考，是否有时可以使用扩展方法，但不应该使用

---

我真的想不出任何理由，但我想我会在这里发布，看看是否有人能想出任何其他不应该使用它们的理由。

我想说，当“它们没有让代码的意图更清楚”时，你应该避免使用它们。当然，某些代码（或编码风格）是否“更清晰”，在人与人之间的差异很大，所以这几乎是无用的。（我有一位老板说，我们应该避免使用接口，因为接口使代码“太复杂，很难理解”）

一般来说，如果您控制程序集的源代码，并且添加方法不会对现有代码造成任何破坏性的更改（例如，如果LINQ没有通过扩展方法实现，情况会是这样）最好只添加一个普通方法。

框架设计指南中关于扩展方法的部分包含了一些很好的建议。我认为您场景的相关部分是：

提供与接口的每个实现相关的助手功能，前提是所述功能可以用核心接口编写

---

如果您建议的用法未通过该测试，则应将其删除。

任何时候，只要您的函数对某一类型的对象“普遍适用”，无论其状态如何，扩展方法都是一个不错的选择

例如，今天我在代码库中添加了两种新的扩展方法：

public static XElement ToXElement(this XmlElement element) { }

public static XmlElement ToXmlElement(this XElement element) { }

一般来说，无论实例的状态如何或我们在何处使用它，这两种方法在它们扩展的类型上都是有效的

如果您的方法不符合该条件，则可能应该将其移动到更接近上下文的帮助器方法，在该上下文中，特定情况始终为真或易于检查

例如，一位开发人员最近指定此为扩展方法：

public static bool ParseYesNoBool(this string input) { }

这里有两个问题：第一，这将出现在应用程序中的所有字符串上，即使可能成为这种情况候选字符串的数量非常少。因此，我们打破了第一条规则，即无论状态如何，它都没有用处。类似地，但第二，此功能的使用者仅限于一个PAR对于外部系统的一个特定连接器，将特定于实现的功能提升到通用名称空间是没有意义的。这已降级为解析器中的帮助器方法

就可读性和调试而言，对于任何具有合理技能水平的开发人员来说，这都是不正确的

扩展方法使您能够向现有类型“添加”方法，而无需创建新的派生类型、重新编译或以其他方式修改原始类型

任何时候，如果您违反了该功能的意图和设计，我建议您重新考虑使用扩展方法。我看到了一些您不想使用扩展方法的情况：

public static bool ParseYesNoBool(this string input) { }

1） 更改对象模型以允许扩展方法：要在其上创建扩展的类是抽象类。这将要求您要么使每个继承的类成为自己的扩展版本，要么从类中删除抽象。无论哪种方式，您都在更改对象模型以使用扩展方法

2） 忘记：为类创建的扩展方法数量超过三个。我发现使用装饰对象比使用扩展对象更容易组织/通信和维护域/对象模型。然而，情况正好相反：如果一个装饰对象的方法少于四种，我会在我的项目中发现很多几乎“空”的对象

---

3） 私有函数：私有函数用于修改（创建、删除等）对象和扩展方法用于使用类型，就像结构一样。如果您发现扩展正在分配给该类型的另一个实例，那么它可能不应该在扩展中。

查看本文@谢谢你的文章。它有点长，所以我会在几分钟后阅读并发回。但这看起来像是我一直在想的事情。我只是想知道你怎么会有一个糟糕的情况。我猜，如果你把与类或接口无关的方法作为扩展方法来使用，那就是其中的一种情况。p、 你的老板听起来像一个真正的OOP大师：PI会看看我是否能挖掘出这个场景，并在这里发布一个修改过的解释。我和一个拥有一个巨大的对象扩展文件的人一起工作，大多数扩展文件都非常具体。我几乎不得不开始学习愤怒管理课程……这两个例子都很好地说明了什么时候应该使用愤怒管理课程，什么时候不应该使用愤怒管理课程。我见过类似的情况，在clr对象中添加了特定于对象的功能。他们正在检查类型中特定于域对象的规则，只想向类型中添加扩展方法以使其更简单。我想我还有一个问题要问，所以我会发帖，而不是试图把它全部放在这篇评论中？另外，让它可以搜索以备将来参考。所以我跳过了这个问题