Java 在您的软件项目中使用“Utils”类是否好？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/3305511/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Is it good to have "Utils" class in your software project?
提问by Cheok Yan Cheng
Usually, during software development, there are all sorts of utility functions I need. Like zipped file, extract zip file, launching Web Browser, get scaled image...
通常，在软件开发过程中，我需要各种实用功能。像压缩文件，解压缩 zip 文件，启动 Web 浏览器，获取缩放图像...
What I did is, I place all this utility functions as static function within a single class named "Utils"
我所做的是，我将所有这些实用程序函数作为静态函数放在一个名为“Utils”的类中
https://github.com/yccheok/jstock/blob/master/src/org/yccheok/jstock/gui/Utils.java
https://github.com/yccheok/jstock/blob/master/src/org/yccheok/jstock/gui/Utils.java
Is it a good practice? Will things grow unmanageable when the number of functions grow larger and larger?
这是一个好习惯吗？当功能越来越多时，事情会变得难以管理吗？
采纳答案by Jose Diaz
Its absolutely a best practice! you don't want to mix all those utility functions with the rest of your application business logic. However, as your utils files and/or classes grow it is recommended to group them according to the function they provide.
这绝对是最佳实践！您不想将所有这些实用程序功能与应用程序业务逻辑的其余部分混合在一起。但是，随着您的 utils 文件和/或类的增长，建议根据它们提供的功能对它们进行分组。
For example, in a web application you could end up with a package structure like this.
例如，在 Web 应用程序中，您可能会得到这样的包结构。
org.sample.web.model
org.sample.web.utils
org.sample.web.validators
org.sample.web.validators.utils
回答by Dustin Laine
I agree with Mike's comment. I use C#, but similar implementation. I have a util project that I maintain secretly and then just drop the DLL in the new project. That way as bugs/changes occur I can update projects simply by replacing DLL.
我同意迈克的评论。我使用 C#，但类似的实现。我有一个我秘密维护的 util 项目，然后将 DLL 放到新项目中。这样，当出现错误/更改时，我可以简单地通过替换 DLL 来更新项目。
I do keep a separate class for different areas of the application as Mike suggested in his comment.
正如 Mike 在评论中所建议的那样，我确实为应用程序的不同领域保留了一个单独的类。
回答by paxdiablo
Yes, utility classes are a good idea but, as with all object-oriented programming, you should be aiming for maximum cohesion, minimal coupling.
是的，实用程序类是一个好主意，但是，与所有面向对象的编程一样，您应该以最大的内聚力和最小的耦合为目标。
Maximum cohesion means that everything in a single class should be heavily related to each other.Minimal coupling means there should be no unnecessary dependencies betweenclasses.
最大内聚意味着单个类中的所有内容都应该彼此密切相关。最小耦合意味着类之间不应该有不必要的依赖关系。
In other words, lumping together compression with image manipulation or the launching of external processes in a single class is a bad idea. By all means have a compression utility class and an image manipulation utility class but don'tput them together.
换句话说，将压缩与图像处理或在单个类中启动外部进程混为一谈是一个坏主意。一定要有一个压缩实用程序类和一个图像处理实用程序类，但不要将它们放在一起。
Doing so is akin to using the singleton pattern as a god object, a ghetto where you just dump all your rubbish that should be better organised. I would say it's okay to use an uber-utility class during development but make sure your code is better organised before shipping. Maintenance will be a lot easier.
这样做类似于使用单例模式作为一个上帝对象，一个你只需倾倒所有应该更好组织的垃圾的贫民窟。我会说在开发过程中使用 uber-utility 类是可以的，但在发布之前确保你的代码组织得更好。维护会容易很多。
Is it a good practice?
这是一个好习惯吗？
No, not in the long term although it's useful when done temporarily.
不，虽然它在临时完成时很有用，但从长远来看不是这样。
Will things grow unmanageable when the number of functions grow larger and larger?
当功能越来越多时，事情会变得难以管理吗？
Yes, no question about it.
是的，毫无疑问。
回答by Uri
A util class (or package of classes) is very useful. I generally tend to separate my utils by functionality into classes, so I may have FileUtils, DatabaseUtils, etc.
util 类（或类包）非常有用。我通常倾向于按功能将我的 utils 分成类，所以我可能有 FileUtils、DatabaseUtils 等。
I would highly suggest, however, maintaining your utils in a separate jar or project (very easy with Eclipse). If you end up having multiple projects that use the same utilities, it is a good idea to avoid code replication. Having a project or jar to include is priceless.
但是，我强烈建议在单独的 jar 或项目中维护您的实用程序（使用 Eclipse 非常容易）。如果您最终拥有多个使用相同实用程序的项目，最好避免代码复制。包含一个项目或 jar 是无价的。
回答by yclian
My practice is to have both *Utilsclases and *Helperclasses. The former contains reusable static functions (for the case of Java and PHP) that are application-unrelated, where the latter are reusable application/domain logics - non static methods and usually with dependencies to other services/beans/managers.
我的做法是既有班级*Utils又有*Helper班级。前者包含与应用程序无关的可重用静态函数（对于 Java 和 PHP），后者是可重用的应用程序/域逻辑 - 非静态方法，通常依赖于其他服务/bean/管理器。
These are a few rules that I apply before I create a method or a *Utilsclass:
这些是我在创建方法或*Utils类之前应用的一些规则：
- Does the language itself already support it?
- Does Apache Commons support it? (or some other common libraries - because someone might have written something that does it better than you)
- How can I make it reusable (project-/app-neutral) so that my other projects can use it?
- How shall I name it? (Yes, it shall always be categorized and separated, because these classes will eventually grow and you may lose control on them when more developers add more methods to it.)
- 语言本身是否已经支持它？
- Apache Commons 是否支持它？（或其他一些常见的库——因为有人可能写的东西比你做得更好）
- 我怎样才能使它可重用（项目/应用中立），以便我的其他项目可以使用它？
- 我该如何命名？（是的，它应该始终被分类和分离，因为这些类最终会增长，当更多的开发人员向其中添加更多方法时，您可能会失去对它们的控制。）
回答by Jerod Houghtelling
Utility classes usually tend to produce procedure style code. The go against pure OO conventions. However, they simplify your life so use them. But have each one do it's own thing otherwise you will end up with a God class that will become a catch all for methods that don't quite seem to fit the object they should reside on.
实用程序类通常倾向于生成过程风格的代码。违背纯 OO 约定。但是，它们可以简化您的生活，因此请使用它们。但是让每个人做自己的事情，否则你最终会得到一个 God 类，它会成为所有似乎不太适合它们应该驻留的对象的方法的集合。
回答by Chocula
Breaking up the utilities is a good approach. In general you want to avoid turning your classes into blobs.
拆分公用事业是一个很好的方法。通常，您希望避免将类变成 blob。
回答by Truong Ha
Is it a good practice?
这是一个好习惯吗？
In most cases, I use this way.
在大多数情况下，我使用这种方式。
as with all object-oriented programming, you should be aiming for maximum cohesion, minimal coupling.
与所有面向对象的编程一样，您的目标应该是最大的内聚性和最小的耦合。
Don't kill your productivity by strictly following those rules, you can see many great frameworks out there break them.
不要因为严格遵循这些规则而扼杀了你的生产力，你会看到许多优秀的框架打破了它们。
回答by CurtainDog
No, I don't think utilities classes are a good practice. Psycologically, the word 'Utilities' is just too broad and even if you split it into multiple classes *Util will just become a dumping ground for things that are 'too difficult' to fit into a proper class design.
不，我不认为实用程序类是一个好习惯。从心理学上讲，“Utilities”这个词太宽泛了，即使你把它分成多个类，*Util 也只会成为“太难”而无法融入适当的类设计的东西的垃圾场。
For an example take a pseudo-ficticious StringUtils class. You could have hundreds of methods for encoding/decoding for different schemes, case transformations, handling whitespace, etc. A better approach, I think, is to use the strategy pattern to handle these transformations, which potentially would even allow for the possibilty of client code introducing new transforms without needing to edit/recompile the original code. You get a more powerful, more flexible and more maintainable system.
以一个伪虚构的 StringUtils 类为例。你可以有数百种方法来编码/解码不同的方案、大小写转换、处理空格等。我认为更好的方法是使用策略模式来处理这些转换，这甚至可能允许客户端的可能性无需编辑/重新编译原始代码即可引入新转换的代码。您将获得更强大、更灵活且更易于维护的系统。
回答by Hyman
If it's at least static, then it makes sense in a Utilclass. That's easy! Cohesion and coupling are meant to make your life easier, this is a clear situation in which they wouldn't, so I would suggest to just keep it up your way.
如果它至少是static，那么它在Util类中是有意义的。这很容易！内聚和耦合是为了让你的生活更轻松，这是一个明显的情况，他们不会，所以我建议你继续坚持下去。
