Re: Design Question
Rhino wrote:
Am I correct in assuming that a valid example of 'state' is the Locale
used by the class/methods to generate error messages?
If the locale is maintained between calls, then its part of the object
state. If it's only used as a method parameter, then it's not part of
the object state but just the current invocation.
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.
If you have a meaningful constructor, you have left static-land and
are now committed to instance-land. If you are building a utility
class, everything must be static. If you are building a helper class,
then make it instantiable and don't use static methods.
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.
"Ugly"? "Ugly"? What is that supposed to mean?
If you are making a utility class with all static methods, you need to
pass the Locale as an argument.
If you are making a helper class with instance methods, then by all
means use the constructors to initialize a private final variable for
Locale.
What's the best way to handle Locale-sensitive messages if I want to
keep my methods static and my constructors private?
Pass the Locale as a method argument.
Remember, the utility class with all static methods must have only
class-level state, not instance-level.
"State" is a standard term; it refers to the current values of
variables associated with the instance.
You can have 'static' state, that is, state maintained by class
variables as opposed to instance variables. The state is associated
with the class as such, and thus does not hurt your staticness.
Static state risks thread issues; the safest thing for static state is
that it be immutable where it exists at all.
Or does this factor change everything and now justify keeping the
StringUtils constructors public and its methods non-static?
Since your analysis indicates that you need multiple instances of your
'StringUtil' class, each with different behaviors, you have answered
your own question.
--
Lew