Is it good to have the "Utils" class in your software project?

Question

Usually during software development I need all sorts of useful features. Like a zip file, extracting a zip file, launching a web browser, getting a scaled image ...

What I did, I put all these utility functions as a static function within the same class called "Utils"

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

Is this a good practice? Will things be uncontrollable when the number of functions increases and increases?

Answer 1

This is absolutely the best practice! You do not want to mix all these utility functions with the rest of the business logic of the application. However, as your utils files and / or classes grow, it is recommended that you group them according to the function they provide.

For example, in a web application, you can create a package structure like this.

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

Answer 2

Yes, useful classes are a good idea, but, as with any object-oriented programming, you should strive for maximum cohesion, minimal communication.

Maximum grip means that everything in the same class must be strongly connected to each other. Minimal communication means that there should not be unnecessary dependencies between classes.

In other words, joint compression with image manipulation or the start of external processes in one class is a bad idea. In every sense, there is a compression utility class and an image processing utility class, but do not combine them.

This is similar to using the singleton pattern as a god object, a ghetto where you simply dump all your garbage that needs to be better organized. I would say it's good to use the uber-utility class at design time, but make sure your code is better organized before submitting. The service will be much easier.

Is this a good practice?

No, not in the long run, although it is useful when done temporarily.

Will things be unmanageable when the number of functions increases and increases?

Yes, no question about that.

Answer 3

No, I don’t think recycling classes are good practice. Psychologically, the word "Utilities" is too large and even if you divide it into several classes * Util will become just a dump for things that are "too complicated" to fit into the correct class design.

Take the pseudo-dummy StringUtils class as an example. You can have hundreds of encoding / decoding methods for different schemes, case transformations, handling spaces, etc. The best approach, I think, is to use a strategy template to handle these transformations, which could potentially even allow the client the ability to enter new transformations without the need to edit / recompile the source code. You get a more powerful, flexible and convenient system.

Answer 4

If it is no less static , then it makes sense in the Util class. It's simple! Cohesion and grip are designed to make your life easier. , this is a clear situation in which they do not, so I would suggest just keeping it on the road.

Answer 5

Is this a good practice?

In most cases, I use this way.

as with any object-oriented programming, you should strive for maximum cohesion, minimal communication.

Do not kill your productivity, strictly following these rules, you can see how many great frameworks break them there.

Answer 6

In fact, the concept of Utils and Helper classes is due to the inability to write free functions in environments where each function must belong to a class (due to language or project limitations). The Utils class, in which there is nothing but static functions, becomes the role of a package with free functions.

Since this is a recurring phenomenon in many software projects, I would consider it a little idiom for OOP projects and, therefore, good practice, because people relate to it. As other answers point out, a useful advantage would be to separate the Utils classes into a separate project to facilitate reuse and maintenance.

Answer 7

I agree with Mike's comment. I use C #, but a similar implementation. I have a utility project that I keep secret and then just drop the DLL into a new project. Thus, as errors / changes occur, I can update projects by simply replacing the DLL.

I keep a separate class for different areas of the application, as Mike suggested in his comment.

Answer 8

A usage class (or class package) is very useful. Usually, I usually separate my utilities into classes by functionality, so I can have FileUtils, DatabaseUtils, etc.

I would highly recommend, however, storing your utilities in a separate bank or project (very easy with Eclipse). If you have several projects that use the same utilities, it is recommended that code replication be avoided. Having a project or banks to include is invaluable.

Answer 9

My practice is to have both *Utils and *Helper classes. The first contains reusable static functions (for Java and PHP) that are not related to each other, where the latter are reusable application / domain logics - non-stationary methods and usually with dependencies with other services / beans / managers.

These are a few rules that I apply before creating a method or *Utils class:

• Does the language itself already support it?
• Does Apache Commons support? (or some other shared libraries - because someone could write something that makes it better than you)
• How can I make it reusable (project / application neutral) so that my other projects can use it?
• What do you call it? (Yes, it should always be classified and separated, because these classes will eventually grow, and you may lose control over them when other developers add more methods to it.)

Answer 10

Utility classes tend to create procedure style code. Campaign Against Net TOE Agreements. However, they simplify your life, so use them. But each of them will do this, otherwise you will end up with the class of God, which will become a ploy for all those methods that do not quite correspond to the object on which they should be.

Answer 11

Utility break is a good approach. In general, you want your classes not to turn into drops.

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