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

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...

What I did is, I place all this utility functions as static function within a single class named "Utils"

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?

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.

For example, in a web application you could end up with a package structure like this.

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

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 between classes.

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't put 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.

>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.

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.

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.

If it's at least static, then it makes sense in a Util class. 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.

Actually, the concept of Utils and Helper classes comes from the inability to write free functions in environments where every function need be owned by a class (either because of language or project restrictions). The Utils class with nothing but static functions ends up acting the role of a package with free functions.

Because it is a recurring phenomenon in many software projects, I'd consider it somewhat of an idiom to OOP designs, and therefore a Good Practice because people relate to it. As other replies point out, a beneficial enhancement would be to factor out your Utils classes to some separate project to facilitate reuse and maintenance.

> 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.

My practice is to have both *Utils clases and *Helper classes. 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.

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

1. Does the language itself already support it?
2. Does Apache Commons support it? (or some other common libraries - because someone might have written something that does it better than you)
3. How can I make it reusable (project-/app-neutral) so that my other projects can use it?
4. 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.)

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.

Breaking up the utilities is a good approach. In general you want to avoid turning your classes into blobs.

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

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.

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

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.

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.