File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Java in General and the fly likes Use of Static methods in Utility Class Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Use of Static methods in Utility Class" Watch "Use of Static methods in Utility Class" New topic
Author

Use of Static methods in Utility Class

Sachin Deokar
Ranch Hand

Joined: May 09, 2008
Posts: 41
Is the use of static method in Utility classes a good idea? If not then what are other better ways to write utility methods?

I am not too fond of using singleton classes or static methods. Would appreciate your suggestions.

Regards,
Sachin Deokar
Jim Hoglund
Ranch Hand

Joined: Jan 09, 2008
Posts: 525
What is it that you don't like about utility classes and/or static methods?
... Jim ...


BEE MBA PMP SCJP-6
Ninad Kulkarni
Ranch Hand

Joined: Aug 31, 2007
Posts: 802

Sachin Deokar wrote:Is the use of static method in Utility classes a good idea? If not then what are other better ways to write utility methods?

I am not too fond of using singleton classes or static methods. Would appreciate your suggestions.

Regards,
Sachin Deokar


May I know why are you not too fond of using singleton pattern or static method?


SCJP 5.0 - JavaRanch FAQ - Java Beginners FAQ - SCJP FAQ - SCJP Mock Tests - Tutorial - JavaSE7 - JavaEE6 -Generics FAQ - JLS - JVM Spec - Java FAQs - Smart Questions
Sachin Deokar
Ranch Hand

Joined: May 09, 2008
Posts: 41
sorry .. let me correct myself .. I dont like over use of static methods. In my last project I ended up using one too many. Thought I would ask you guys If there was any other good alternative to write utility classes.

Sachin
Ninad Kulkarni
Ranch Hand

Joined: Aug 31, 2007
Posts: 802

It depends on code requirement
Ninad Kulkarni
Ranch Hand

Joined: Aug 31, 2007
Posts: 802

Suppose if you need only single instance then use singleton pattern.
If your code requirement satisfied by static utility method then why are you using instance method? For instance method you need instance of an object.
For example if you need polymorphism then you should use instance method.
Seetharaman Venkatasamy
Ranch Hand

Joined: Jan 28, 2008
Posts: 5575

http://www.coderanch.com/t/407852/Beginning-Java/java/why-do-we-use-static

particularly read Campbell Explanation
Sachin Deokar
Ranch Hand

Joined: May 09, 2008
Posts: 41
Thanks Guys for your Replies.

So, are static method only option to write utility methods, or can they be written/accessed any other way? any design pattern that I can follow for writing utility class?

I am just trying to get information on best possible way to write Utility Class making sure I dont end up writing error prone code that is used everywhere in the application.

Thanks again. Appreciate your help.

Sachin
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14338
    
  22

Sachin Deokar wrote:sorry .. let me correct myself .. I dont like over use of static methods. In my last project I ended up using one too many.

That indeed sounds like a code smell (a symptom that there might be something wrong with the design of your program), that the program is not really designed the object oriented way. If you're interested in designing better code, have a look at anti-patterns, there are whole books about this subject.

There are some disadvantages to the singleton pattern, some people say that the singleton is an anti-pattern - mainly because it makes unit testing hard (it adds global state to the program) and because you need to be careful with synchronization if your program is multi-threaded. You can use dependency injection instead of singletons in many cases.

If your utility methods are pure utility methods, that don't retain any state, I'd just make them static methods - but don't use too many of them.

Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 8 API documentation
Yegor Bugayenko
Ranch Hand

Joined: Feb 11, 2011
Posts: 78
Maybe this blog post of myself will help: http://www.yegor256.com/2014/05/05/oop-alternative-to-utility-classes.html


SCEA, PMP, read my blog: www.yegor256.com
Steve Luke
Bartender

Joined: Jan 28, 2003
Posts: 4181
    
  21

Hi Yegor,

Thanks for sharing your blog post. I have a few comments on it though. You have two examples of static utility methods you think would be better replaced with a series of Object based patterns. The second example uses this as the procedural example:

And then transforms it into this OO example:

Where you would have Trimmed, FileLines, and UnicodeFile as custom classes which you write and implement the collections API, and provide all kinds of other benefits you describe. Many of the problems you describe seem to be because you are using a poorly written transform method to begin with. For example, you say this:
Besides that, it is obvious that the second script runs in O(1) space, while the first one executes in O(n). This is the consequence of our procedural approach to data in the first script.

I don't see how the second example performs in O(1) time! It performs in O(n) time where n is the number of lines in the file. The procedural approach runs in O(3n) time, but that is only because it is poorly written. It could, for example, do this:

Barring any coding mistakes in that bit, this is O(n), doesn't read from the file until it can store the results, doesn't hold intermediate results, all benefits you give as reasons to use the OO implementation. It could be static since it doesn't access any state, and so could be put into a utility method. The use of the transformer and encoding String (the encoding could probably be eliminated if I though a bit about it, like having decorated transformers or something). But I wouldn't need to right all the code required to make the intermediate classes (Trimmer, FileLines, UnicodeFile) implement Collection<String> properly. And fewer lines of code means less bugs, and both less bugs and less time spent implementing a huge interface means more productivity in other areas.

So I guess I have a few questions and comments:
1) How do you figure your OO code is O(1) and not O(n)?
2) I would suggest you not compare good OO code to bad procedural code when trying to make general statements like 'Utility classes are evil'.
3) Is the general statement that you are trying to get across that Utility classes make it easier to write poor procedural code by providing easy to use small chunks that lets the user of the Utility write lazy code which does not effectively do the job. If so, then I think you should make that more explicit in the blog. Otherwise it looks more like you are comparing apples to oranges and concluding blueberries are best.


Steve
Janeice DelVecchio
Saloon Keeper

Joined: Sep 14, 2009
Posts: 1726
    
  12

I think, just like most things, static utility classes are best in moderation.

You have to be aware that static methods are difficult to unit test. So make them do really specific things that can be tested on their own and the caller won't need to want to mock out.
Even then, you could "mock out" your static call if you encapsulate it into a method, then override it with your own "mocked" behavior. If you had to. Or create an adapter/bridge.

What happens in some (older) apps, is that folks wanted to get the "performance benefit" of using static utilities over testability, maintainability, etc.

Personally, I think that if you're doing math, string manipulation, date converting.... those things "belong" in utility classes. Because you can do them regardless of the "business logic" of the application, and you're likely doing them in lots of places, and you can trust the methods do exactly what they say on the label.


When you do things right, people won't be sure you've done anything at all.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39784
    
  28
Utility classes are good place to put functions. Things mathematical as Janeice says are prime candidates to be functions and to be put into utility classes. Functions always return the same result from the same input so do not depend on instance variables.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Use of Static methods in Utility Class