类名中的“Helper”一词是代码气味吗？

Posted 2023-02-15

【中文标题】类名中的“Helper”一词是代码气味吗？

【英文标题】：Is the word "Helper" in a class name a code smell?

【发布时间】：2011-01-27 15:08:45

【问题描述】：

我们似乎从网页中抽象出很多逻辑方式并创建“帮助”类。可悲的是，这些课程听起来都一样，例如

ADHelper，（活动目录） 认证助手， SharePoint 助手

其他人是否有大量具有这种命名约定的类？

【问题讨论】：

相关：***.com/questions/562971/smelly-class-names

objology.blogspot.com/2011/09/…

【参考方案1】：

我会说它符合代码异味，但请记住，代码异味不一定会带来麻烦。这是你应该调查的事情，然后决定是否可以。

话虽如此，我个人认为这样的名称几乎没有增加价值，而且因为它非常通用，所以该类型很容易成为一堆不相关的实用方法。 IE。一个助手类可能会变成一个大类，它是common code smells 之一。

如果可能的话，我建议找到一个更准确地描述这些方法的作用的类型名称。当然，这可能会提示额外的辅助类，但只要它们的名称有帮助，我不介意这些数字。

前段时间，我在代码审查期间遇到了一个名为 XmlHelper 的类。它有许多方法显然都与 Xml 有关。但是，从类型名称中并不清楚这些方法有什么共同点（除了与 Xml 相关）。事实证明，其中一些方法正在格式化 Xml，而另一些方法正在解析 Xml。因此，IMO 该类应该被分成两个或更多部分，并具有更具体的名称。

【参考方案2】：

与往常一样，这取决于上下文。

当您使用您自己的 API 时，我肯定会认为这是代码异味，因为 FooHelper 表示它在 Foo 上运行，但该行为很可能直接属于 @ 987654323@班级。

但是，当您使用现有 API（例如 BCL 中的类型）时，您无法更改实现，因此 扩展方法 成为其中一种方式以解决原始 API 中的缺点。您可以选择将此类类命名为 FooHelper 和 FooExtension。它同样臭（或没有）。

【参考方案3】：

取决于课程的实际内容。

如果大量的实际业务逻辑/业务规则在 辅助类中，那么我会说是的。

如果这些类真的只是可以在其他企业应用程序中使用的助手（绝对意义上的重用——而不是复制然后自定义），那么我会说助手不是代码味道。

【讨论】：

将业务逻辑的数量考虑在内是个好主意。为此 +1。

【参考方案4】：

这是一个有趣的观点，如果一个词在名称中变成“样板”，那么它可能有点奇怪——如果不是真正的气味的话。也许使用“Helper”文件夹，然后允许它出现在命名空间中，这样可以保持它的使用，而不会过度使用这个词？

Application.Helper.SharePoint
Application.Helper.Authentication

等等

【参考方案5】：

在很多情况下，我使用以Helper 结尾的类来表示包含扩展方法的静态类。在我看来并不臭。您不能将它们放入非静态类中，而类本身并不重要，所以我认为 Helper 很好。这样的类的用户无论如何都不会看到类名。

.NET Framework 也可以做到这一点（例如，在 WPF 的 LogicalTreeHelper 类中，它只有一些静态（非扩展）方法）。

问问自己，如果将帮助类中的代码重构为“真实”类（即适合您的类层次结构的对象），代码是否会更好。代码必须在某个地方，如果你不能找出它真正属于的类/对象，比如简单的辅助函数（因此是“Helper”），你应该没问题。

【讨论】：

我认为很多 ASP.NET Web 开发人员使用静态类是因为他们熟悉它们并且知道如何正确使用它们，例如：Console.WriteLine("Hello World!");但是 php Web 开发人员需要代码异味。作为 Web 开发人员，我们所要做的就是能够重用我们的代码并编写干净的松散耦合组件。当我为两种语言的 html 输出按摩数据时，我使用静态类。我喜欢使用命名空间来组织我的助手，这样我可以在类名中省略“助手”这个词。

【参考方案6】：

我不会说这是代码异味。在 ASP.NET MVC 中这很常见。