• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Use of Static methods in Utility Class

 
Sachin Deokar
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 525
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What is it that you don't like about utility classes and/or static methods?
... Jim ...
 
Ninad Kulkarni
Ranch Hand
Posts: 802
Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Sachin Deokar
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 802
Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It depends on code requirement
 
Ninad Kulkarni
Ranch Hand
Posts: 802
Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 5575
Eclipse IDE Java Windows XP
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
http://www.coderanch.com/t/407852/Beginning-Java/java/why-do-we-use-static

particularly read Campbell Explanation
 
Sachin Deokar
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 15448
42
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Yegor Bugayenko
Ranch Hand
Posts: 80
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Maybe this blog post of myself will help: http://www.yegor256.com/2014/05/05/oop-alternative-to-utility-classes.html
 
Steve Luke
Bartender
Posts: 4181
22
IntelliJ IDE Java Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Janeice DelVecchio
Saloon Keeper
Posts: 1809
12
Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

 
Campbell Ritchie
Sheriff
Pie
Posts: 49827
69
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic