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

Question

在你开始指向重复之前,我只知道我已经阅读了关于扩展方法的几乎所有关于SO的帖子.我只是想在一分钟内扮演魔鬼的拥护者,考虑替代我的工作意见.

最近我正在研究一个项目,并且需要一种方法作为接口的基础.所以我建议我们写一个扩展方法,它被击落了.说它增加了复杂性并且更难调试.

我当然争论并找到了所有精彩的帖子,这些帖子显示了使用扩展方法的许多原因.不要忘记很多.net框架都使用它们.我们最终没有使用它,因为我被团队推翻了.

但是它让我思考,是否有时候可以使用扩展方法但不应该使用？

我真的想不出任何想法,但我想在这里发帖,看看是否有人能想到为什么不应该使用它们的任何其他原因.

Answer 1

每当你有一个"普遍适用"某种类型的对象的函数时,无论其状态如何,扩展方法都是一个不错的选择.

例如,今天我在代码库中添加了两个新的扩展方法:

public static XElement ToXElement(this XmlElement element) { }

public static XmlElement ToXmlElement(this XElement element) { }

一般来说,无论实例的状态或我们使用它的位置,这两种方式都有效.

如果您的方法不符合该标准,则应该将其移动到更靠近特定情况始终为真或易于检查的上下文的辅助方法.

例如,开发人员最近提名这是一个扩展方法:

public static bool ParseYesNoBool(this string input) { }

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

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