Homegrown utility methods

Question

Static utility methods are generally frowned up by OO purists.

I was wondering however what people feel about utility methods that are used to avoid something simple like a null check throughout the application.

String.trim() throws a NPE when invoked on a null String. So I have to do:

if(str!=null) 
     setValue(str.trim());
else
     setValue("");

What if I create a utility method that checks for the null?

setValue(myTrim(str));

public static String myTrim(String str) {

  if(str==null) return "" 

  else return str.trim();
}

The one problem I have encountered with methods like these is that some developers on the team might not like/not know this utility and might be doing staight calls after doing a null comparison.

Is this something that you do your framework too? If yes, what are the other common utility general use methods that people have created and are using in their applications?

What do you feel are the pros and cons of either approach?

Answer 1

some developers on the team might not like/not know this utility

That's what communication is good for. And I don't mean e-mail.

Talks about these kind of functions, probably other team members are doing the same and by not communitating you're duplicating code and efforts.

You may find a way to use these utility methods or even some more experienced developer migth have already develop a more mature lib or used a 3rd party.

But by all means, communicate with your team

Answer 2

I'm not an OO purist. So i love stuff like this. Anything that makes it easier to write code that reflects my intentions without getting bogged down in irrelevant details.

Write it. Use it yourself. Don't be shy - demonstrate how much cleaner it makes your code. Worst case, at least there'll be a bit less repetition in your code...

Answer 3

I'd be inclined to replace the homegrown uses when an existing library (like Apache Commons Blah Blah Blah) already has written it. Code you can offload to someone else lets you focus on the important parts of the software that truly differentiate your work from everyone else's. But yes, utility classes with static methods are great, if they need to be written by you at all.

FYI, take a look at StringUtils.trimToEmpty(). Good luck.

Answer 4

I have a few classes that just contain fave static methods - they do make sense to have. You can put together extensive unit tests checking any and all boundary conditions.

In the case you described though - wouldn't it be better to make the setValue method accept any string sent to it? The method could then apply a default null string, trim it or even throw an exception if the value was incorrect.

The JavaDoc on that routine can then clearly state what inputs are valid/invalid and what happens to invalid inputs.

Not saying this is right - just another viewpoint

Answer 5

In terms of a design principle, there are some things that are just more logically static methods. If the utility class that you're writing doesn't really have any "state", and it feels more logical to make it uninstantiable with a bunch of static methods, then do it like that. But make sure your class is genuinely uninstantiable (give it a private constructor; I've seen people declare the class as abstract, but that's no good because people can override it).

The problem that you then get into is that if your class is project-wide, you need to treat it as a library class. And writing libraries is different from writing general code:

• in general code, you should profile rather than prematurely optimising; but in a library method, you can't predict how people will use your call in the future;
• you need to be very careful to document or clearly name what your method does;
• you need to give it generic behaviour, and not be blinded by some specific feature that you need at that moment (e.g. if you have a method to "tokenise a string", what do you do with empty tokens? if you need to ignore them, will other callers to your method?)

Answer 6

I use a lot of utility functions. There are some things that just don't need "objects", but I don't like the particular example you have of trim().

A reference to string that is null is very different from an empty string. Unless the app is very simple, and you know you always want to read a null reference as "", I wouldn't do it. For this case, I prefer:

setValue((str != null) ? str.trim() : "")

For me, an uncaught NPE is a good indication that there's a major error going on in the application!