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