类名称中的“助手”一词是否有代码味道？

我们似乎正在从网页中抽象出很多逻辑方式并创建“帮助”类。可悲的是，这些类都拉响相同，e.g类名称中的“助手”一词是否有代码味道？

ADHelper，（活动目录） AuthenicationHelper， SharePointHelper

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

来源

2010-03-15 Kye

相关：http://stackoverflow.com/questions/562971/smelly-class-names – 2010-03-15 10:50:22

http://objology.blogspot.com/2011/09/one-of-best-bits-of-programming-advice .html？spref = tw – 2011-09-27 13:56:30

我会说它有资格作为代码味道，但请记住，代码味道不一定拼写麻烦。这是你应该看看，然后决定是否可以。

话虽如此，我个人发现这样的名字增加了很少的价值，因为它是如此通用的类型可能很容易成为一个非相关的效用方法的桶。即辅助班可能会变成大班，这是common code smells之一。

如果可能，我建议找到一个更接近描述方法的类型名称。当然这可能会提示更多的助手类，但只要他们的名字有帮助，我不介意数字。

前段时间我在代码审查过程中遇到了一个名为XmlHelper的类。它有很多方法，显然都与Xml有关。然而，从类型名称中不清楚这些方法有什么共同之处（除了与Xml相关）。事实证明，一些方法是格式化Xml和其他人解析Xml。所以海事组织这个班应该分成两部分或更多部分，并且有更具体的名字。

来源

2010-03-15 10:50:01

-3

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

来源

2010-03-15 10:31:57

取决于类的实际内容。

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

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

来源

2010-03-15 10:34:39

考虑到业务逻辑的数量是一个好主意。 +1。 – OregonGhost 2010-03-15 10:40:35

一如既往，这取决于上下文。

当你与自己的API工作，我一定会认为这是一个代码味道，因为FooHelper表明它Foo工作，但行为很可能会直接属于上Foo类。

然而，当你与现有的API（例如BCL中的类型）的工作，你不能改变的实施，使扩展方法成为解决原来的API中的缺陷的方法之一。您可以选择命名FooHelper以及FooExtension。它同样臭（或不）。

来源

2010-03-15 10:37:21

这是一个有趣的观点，如果一个单词在名称中变成'样板文件'，那么它可能会有些微妙 - 如果不是真正的气味。也许使用'Helper'文件夹，然后让它出现在命名空间中，可以保持它的使用而不会过度使用这个单词？

Application.Helper.SharePoint 
Application.Helper.Authentication

等

来源

2010-03-15 10:38:58 amelvin

在许多情况下，我使用类与Helper包含扩展方法的静态类结束。对我来说似乎并不臭。你不能把它们放到一个非静态的类中，而且类本身并不重要，所以我认为Helper很好。无论如何，这样的班级的用户都不会看到班级名称。

.NET框架也这样做（例如在WPF的LogicalTreeHelper类中，它只有一些静态（非扩展）方法）。

问问你自己，如果你的助手类中的代码会被重构为“真实”类，即适合你的类层次结构的对象，那么代码会更好。代码有在某个地方，如果你不能确定它真正属于的类/对象，就像简单的帮助函数（因此“助手”），你应该没问题。

来源

2010-03-15 10:39:25 OregonGhost

我认为很多ASP.NET Web Devs都使用静态类，因为他们熟悉它们并知道如何正确使用它们，例如：Console.WriteLine（“Hello World！”）;但PHP Web Devs调用代码味道。作为Web开发人员，我们所要做的就是能够重用我们的代码并编写干净松散耦合的组件。我使用静态类来处理两种语言的html输出数据。我喜欢使用命名空间来组织我的助手，这样我就可以在类名中省略单词“助手”。 – yardpenalty 2016-04-06 02:35:50

类名称中的“助手”一词是否有代码味道？

回答

相关问题