扩展方法与助手类 [重复]

Posted 2023-02-22

【中文标题】扩展方法与助手类 [重复]

【英文标题】：Extension Method vs. Helper Class [duplicate]

【发布时间】：2012-07-05 00:49:26

【问题描述】：

可能重复：Extension Methods vs Static Utility Class

我正在构建一个基于 .NET 中的对象执行操作的通用函数 API。例如;我创建了一个函数来检查一个字符串，看看它是否是一个电子邮件地址。

我可以有：

static bool IsEmailAddress(string text)

    return IsMail(text);

或者我可以创建一个可以像这样使用的扩展方法：

string text = "[e-mail]";
if (text.IsEmailAddress())

哪个更合适，或者您认为既然这是一个通用库，我可以在技术上以两种方式实现它并让开发人员决定哪个最适合他们？

【问题讨论】：

顺便说一句： 使用 return IsMail(text) 而不是 if 语句。

我会使用扩展方法和 Mahmoud 建议的重构。

我认为string 没有责任知道电子邮件地址是什么。所以我认为这不应该是一种扩展方法。

你在征求意见，我认为这里不鼓励这样做。

@CodesInChaos 虽然我原则上同意你的观点，在 OPs 代码的上下文中，他对string 印象深刻是一种责任。扩展方法又好又干净又简洁，所以在这种情况下我会这样做。

【参考方案1】：

创建扩展方法意味着当用户使用该类型时，它将在智能感知期间自动显示。您必须小心不要在开发人员浏览的方法列表中添加很多噪音（尤其是在创建可重用框架时）。例如，当这些方法仅在特定上下文中可用时，您可能最好使用“普通”静态方法。特别是在为string等通用类型实现扩展方法时。

以ToXml(this string) 扩展方法或ToInt(this string) 扩展方法为例。尽管拥有这些扩展方法看起来很方便，但将文本转换为 XML 并不是您在整个应用程序中都会做的事情，而且 XmlHelper.ToXml(someString) 会很容易。

只有一件事更糟糕，那就是在object上添加一个扩展方法。

如果您正在编写一个可重用的框架，the book Framework-Design-Guidelines by Krzysztof Cwalina 是绝对必读的。

【讨论】：

不要忘记扩展名绑定到命名空间——所以除非你没有在你的客户端类中指定扩展名的命名空间——否则你的扩展方法的智能感知不会出现。另一件事扩展到底是什么？ - 编译后 - 它是带有静态方法的静态类 - 所以我宁愿使用扩展作为语法糖，并拥有良好的命名空间结构，而不是创建 StaticHelpers。

【参考方案2】：

我更喜欢扩展方法，因为你的代码很优雅，你可以在框架的密封类上定义扩展方法。

【参考方案3】：

问题是您将针对哪个 .NET Framework？如果

【参考方案4】：

扩展方法自动成为静态类的一部分。这意味着消费者可以使用扩展方法，也可以根据需要从类中调用静态方法。我尽可能多地使用扩展方法，如果将它们放在正确的命名空间中，它们会更容易发现。

【参考方案5】：

扩展方法允许开发人员不知道帮助类被调用的确切位置以及它的位置，更不用说它存在的事实了。请注意，您仍然需要将它们的命名空间放在 using 子句中 - 或许将它们放置在您的应用程序的一些通用的***命名空间中。