类名中的"助手"这个词是代码味吗？

Question

我们似乎从网页中抽象了许多逻辑方式并创建了"帮助"类.可悲的是,这些课程听起来都是一样的,例如

ADHelper,(Active Directory)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

等等