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

Question

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

ADHelper，（活动目录）AuthenicationHelper，SharePointHelper

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

Answer 1

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

话虽如此，我个人发现这样的名称几乎没有增加价值，而且因为它是如此通用，所以该类型很容易成为一堆不相关的实用方法。即帮助类可能会变成一个大类，这是常见的代码异味之一。

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

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

Answer 2

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

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

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

Answer 3

视课程的实际内容而定。

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

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

Answer 4

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

Application.Helper.SharePoint
Application.Helper.Authentication

等等

Answer 5

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

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

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

Answer 6

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