Google groups.
that's "state" and you should not be using static methods. Basically,
thread is wrong.
public constructors.
...
...
Note now I'm avoiding the static keyword everywhere.
A class who will never have instances with their own state, whose sole
purpose is to provide utility methods for other classes, whose entire
operation depends only on data in the argument lists of those methods,
and ultimately, for whom it really never adds value to have an
instance, is called a "utility class" and likely should have
instantiation prevented and all its members static.
Declaring a class final does not prevent its instantiation. Declaring
its constructor private does, and also prevents subclassing, making
the 'final' declaration redundant, so don't bother with it.
I've read all the replies to this thread and have been trying to post
followup questions since yesterday afternoon; unfortunately, I've had
major problems with the news server and have finally had to resort to
posting via Google groups. Sorry for the delay!
--
Am I correct in assuming that a valid example of 'state' is the Locale
used by the class/methods to generate error messages?
My StringUtils class generates a substantial number of error messages
via the standard ResourceBundle mechanism and delivers them in a
Locale-sensitive fashion. I have two constructors for StringUtils, one
that has no parameters and simply uses the default Locale, and the
other, which has the Locale desired by the user as the single
parameter.
Now, if I want to continue to deliver Locale-sensitive messages and if
I make the constructors private, I can't tell the methods which Locale
to use in selecting message files via the constructor. I suppose I
could add a Locale parameter to each method's parameter list but that
seems ugly.
What's the best way to handle Locale-sensitive messages if I want to
keep my methods static and my constructors private?
Or does this factor change everything and now justify keeping the
StringUtils constructors public and its methods non-static?
--
Rhino