“帮手”这个词是吗？类名中有代码味道？
我们似乎从网页中抽象出很多逻辑方式并创建“帮助”类。遗憾的是，这些类听起来都一样，例如
ADHelper（Active Directory） 身份验证助手， SharePointHelper
其他人是否有大量采用此命名约定的类？
We seems to be abstracting a lot of logic way from web pages and creating "helper" classes. Sadly, these classes are all sounding the same, e.g
ADHelper, (Active Directory)
AuthenicationHelper,
SharePointHelper
Do other people have a large number of classes with this naming convention?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我想说它符合代码异味，但请记住代码异味并不一定会带来麻烦。这是您应该调查的事情，然后决定是否可以。
话虽如此，我个人发现这样的名称几乎没有什么价值，而且因为它是如此通用，所以类型很容易成为一堆不相关的实用方法。即，辅助类可能会变成大型类，这是常见代码味道之一。
如果可能的话，我建议找到一个更贴切地描述方法功能的类型名称。当然，这可能会提示额外的帮助类，但只要它们的名字有帮助，我不介意这些数字。
前段时间，我在代码审查期间遇到了一个名为 XmlHelper 的类。它有许多方法，显然都与 Xml 有关。然而，从类型名称中并不清楚这些方法有什么共同点（除了与 Xml 相关之外）。原来，有些方法是格式化Xml，有些方法是解析Xml。因此，在我看来，该类应该被分成两个或多个具有更具体名称的部分。
I would say that it qualifies as a code smell, but remember that a code smell doesn't necessarily spell trouble. It is something you should look into and then decide if it is okay.
Having said that I personally find that a name like that adds very little value and because it is so generic the type may easily become a bucket of non-related utility methods. I.e. a helper class may turn into a Large Class, which is one of the common code smells.
If possible I suggest finding a type name that more closely describes what the methods do. Of course this may prompt additional helper classes, but as long as their names are helpful I don't mind the numbers.
Some time ago I came across a class called XmlHelper during a code review. It had a number of methods that obviously all had to do with Xml. However, it wasn't clear from the type name what the methods had in common (aside from being Xml-related). It turned out that some of the methods were formatting Xml and others were parsing Xml. So IMO the class should have been split in two or more parts with more specific names.
一如既往，这取决于上下文。
当您使用您自己的 API 时，我肯定会认为它是代码味道，因为
FooHelper表明它在Foo上运行，但行为会最有可能直接属于Foo类。但是，当您使用现有 API（例如 BCL 中的类型）时，您无法更改实现，因此扩展方法成为解决缺点的方法之一在原始 API 中。您可以选择将这些类命名为
FooHelper以及FooExtension。它同样有臭味（或没有臭味）。As always, it depends on the context.
When you work with your own API I would definitely consider it a code smell, because
FooHelperindicates that it operates onFoo, but the behavior would most likely belong directly on theFooclass.However, when you work with existing APIs (such as types in the BCL), you can't change the implementation, so extension methods become one of the ways to address shortcomings in the original API. You could choose to names such classes
FooHelperjust as well asFooExtension. It's equally smelly (or not).取决于实际课程内容。
如果大量的实际业务逻辑/业务规则在帮助器类中，那么我会说是的。
如果这些类实际上只是可以在其他企业应用程序中使用的帮助程序（绝对意义上的重用——不是复制然后定制），那么我会说这些帮助程序不是代码味道。
Depends on the actual content of the classes.
If a huge amount of actual business logic/business rules are in the helper classes, then I would say yes.
If the classes are really just helpers that can be used in other enterprise applications (re-use in the absolute sense of the word -- not copy then customize), then I would say the helpers aren't a code smell.
这是一个有趣的观点，如果一个词在名字中变成了“样板文件”，那么它可能有点难闻——如果不是真正的气味的话。也许使用“Helper”文件夹，然后允许它出现在命名空间中可以保留其用途，而不会过度使用该词？
等等
It is an interesting point, if a word becomes 'boilerplate' in names then its probably a bit whiffy - if not quite a real smell. Perhaps using a 'Helper' folder and then allowing it to appear in the namespace keeps its use without overusing the word?
and so on
在许多情况下，我将以
Helper结尾的类用于包含扩展方法的静态类。我觉得不臭。你不能将它们放入非静态类中，类本身并不重要，所以我认为 Helper 很好。此类的用户无论如何都看不到该类名称。.NET Framework 也执行此操作（例如，在 WPF 的 LogicalTreeHelper 类中，该类仅具有一些静态（非扩展）方法）。
问问自己，如果将辅助类中的代码重构为“真正的”类（即适合类层次结构的对象），代码是否会更好。代码必须位于某个地方，如果您无法确定它真正所属的类/对象，例如简单的辅助函数（因此称为“Helper”），那么您应该没问题。
In many cases, I use classes ending with
Helperfor static classes containing extension methods. Doesn't seem smelly to me. You can't put them into a non-static class, and the class itself does not matter, so Helper is fine, I think. Users of such a class won't see the class name anyway.The .NET Framework does this as well (for example in the
LogicalTreeHelperclass from WPF, which just has a few static (non-extension) methods).Ask yourself if the code would be better if the code in your helper class would be refactored to "real" classes, i.e. objects that fit into your class hierarchy. Code has to be somewhere, and if you can't make out a class/object where it really belongs to, like simple helper functions (hence "Helper"), you should be fine.
我不会说这是代码味道。在 ASP.NET MVC 中这很常见。
I wouldn't say that it is a code smell. In ASP.NET MVC it is quite common.