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

Question

在您开始向我指出重复项之前，请知道我已经阅读了几乎所有关于扩展方法的帖子。我只是想在一分钟内唱反调，以考虑替代我的工作意见的替代方案。

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

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

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

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

Answer 1

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

例如，今天我向我们的代码库添加了两个新的扩展方法:

public static XElement ToXElement(this XmlElement element) { }

public static XmlElement ToXmlElement(this XElement element) { }

一般来说，无论实例的状态或我们在何处使用它，这两者都对它们扩展的类型有效。

如果您的方法不符合该标准，则可能应该将其移至更接近特定情况始终为真或易于检查的上下文的辅助方法。

例如，开发人员最近将此指定为扩展方法:

public static bool ParseYesNoBool(this string input) { }

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

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