Question

通常，在软件开发过程中，我需要各种实用功能。像压缩文件一样，提取zip文件，启动Web浏览器，获得缩放图像......

我所做的是，我将所有这些实用程序函数作为静态函数放在名为“Utils”的单个类中

https://github.com/yccheok/jstock/blob/master/src/org/yccheok/jstock/gui/Utils.java

这是一个好习惯吗？当函数的数量越来越大时，事情会变得无法管理吗？

Answer 1

绝对是最好的做法！您不希望将所有这些实用程序功能与其他应用程序业务逻辑混合使用。但是，随着您的utils文件和/或类的增长，建议根据它们提供的功能对它们进行分组。

例如，在Web应用程序中，您最终可能会得到这样的包结构。

org.sample.web.model
org.sample.web.utils
org.sample.web.validators
org.sample.web.validators.utils

Answer 2

是的，实用程序类是个好主意，但是，与所有面向对象的编程一样，你应该追求最大的内聚力，最小的耦合。

最大内聚意味着单个类中的所有内容都应与彼此密切相关。最小耦合意味着类之间不应存在不必要的依赖。

换句话说，将压缩与图像处理结合在一起或在单个类中启动外部进程是一个坏主意。无论如何都有一个压缩实用程序类和一个图像处理实用程序类，但不将它们放在一起。

这样做类似于使用单身人士模式作为上帝对象，一个贫民窟，你只需要倾倒所有应该更好组织的垃圾。我想说在开发过程中使用超级实用程序类是可以的，但要确保在发货之前更好地组织代码。维护将更容易。

这是一个好习惯吗？

不，从长远来看，虽然临时完成时很有用。

当函数的数量越来越大时，事情会变得难以管理吗？

是的，毫无疑问。

Answer 3

不，我认为公用事业课程不是一个好习惯。从经济学的角度来看，“公用事业”这个词过于宽泛，即使你把它分成多个类别，也只会成为一个倾销场，因为这些东西“难以”适合于适当的阶级设计。

举个例子来看一个伪虚构的StringUtils类。您可以使用数百种方法对不同的方案进行编码/解码，大小写转换，处理空白等。我认为更好的方法是使用策略模式来处理这些转换，这甚至可能允许客户端的可能性代码引入新的转换而无需编辑/重新编译原始代码。您将获得更强大，更灵活，更易维护的系统。

Answer 4

这是一个好习惯吗？

在大多数情况下，我都是这样使用的。

与所有面向对象的编程一样，你的目标应该是最大的内聚力，最小的耦合。

不要严格遵守这些规则来降低你的工作效率，你可以看到许多伟大的框架打破了它们。

Answer 5

如果它至少是静态，那么它在Util类中是有意义的。这很简单！凝聚力和耦合力是为了让你的生活更加轻松，这是一个明显的情况，他们不会，所以我建议你坚持下去。

Answer 6

实际上，Utils和Helper类的概念来自于无法在每个函数需要由类拥有的环境中编写自由函数（由于语言或项目限制）。只有静态函数的Utils类最终会扮演具有自由函数的包的角色。

因为它在许多软件项目中都是一种反复出现的现象，所以我认为它有点像OOP设计的成语，因此是一种良好实践，因为人们与它有关。正如其他回复指出的那样，有益的改进是将您的Utils类分解为某个单独的项目，以促进重用和维护。

Answer 7

我同意迈克的评论。我使用C＃，但类似的实现。我有一个秘密维护的util项目，然后将DLL放入新项目中。这样当出现错误/更改时，我可以简单地通过替换DLL来更新项目。

我确实为申请的不同领域保留了一个单独的课程，正如Mike在评论中所说的那样。

Answer 8

util类（或类包）非常有用。我通常倾向于将我的utils按功能分成类，所以我可能有FileUtils，DatabaseUtils等。

但是，我强烈建议将你的工具保存在一个单独的jar或项目中（使用Eclipse非常容易）。如果最终有多个使用相同实用程序的项目，最好避免代码复制。拥有一个项目或罐子是无价的。

Answer 9

我的做法是同时拥有*Utils条和*Helper类。前者包含与应用无关的可重用静态函数（对于Java和PHP的情况），后者是可重用的应用程序/域逻辑 - 非静态方法，通常与其他服务/ bean /管理器的依赖关系。

这些是我在创建方法或*Utils类之前应用的一些规则：

语言本身是否已经支持它？
Apache Commons是否支持它？（或者其他一些常见的图书馆 - 因为有人可能写了比你更好的东西）。
如何使其可重复使用（项目/应用程序中立）以便我的其他项目可以使用它？
我该如何命名？（是的，它应该总是被分类和分离，因为这些类最终会增长，当更多开发人员为它添加更多方法时，你可能会失去对它们的控制。）

Answer 10

实用程序类通常倾向于生成过程样式代码。违背纯粹的OO惯例。但是，它们会简化您的生活，因此请使用它们但是让每个人都做自己的事情，否则你最终会得到一个上帝类，它将成为一个方法，它们看起来并不适合他们应该居住的对象。

Answer 11

打破公用事业是一种很好的方法。通常，您希望避免将类转换为blob。

http://sourcemaking.com/antipatterns/the-blob

在您的软件项目中使用“Utils”类是否很好？

11 个答案: