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"
Is it a good practice? Will things grow unmanageable when the number of functions grow larger and larger?
Source: Tips4all
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 provided.
ReplyDeleteFor 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
Regards.
Yes, utility classes are a good idea but, as with all object-oriented programming, you should be aiming for maximum cohesion, minimal coupling.
ReplyDeleteMaximum 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 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.
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.
ReplyDeleteIs it a good practice?
ReplyDeleteIn 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.
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.
ReplyDeleteI 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.
ReplyDeleteI 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.
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.
ReplyDeleteThese are a few rules that I apply before I create a method or a *Utils class:
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.)
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.
ReplyDeleteBreaking up the utilities is a good approach. In general you want to avoid turning your classes into blobs.
ReplyDeletehttp://sourcemaking.com/antipatterns/the-blob
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.
ReplyDeleteFor 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.
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.
ReplyDeleteBecause 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.