Re: Design Questions about static factory classes

But I'd like to try to sum up a bit now. The conversation has gotten
sufficiently fragmented that I'm not sure what we would all agree on
with regards to the situation I am trying to resolve.

However, I find myself seriously doubting that Locale SHOULD be a
class variable after all. And if my reasoning is sound, which I hope
you will tell me, I may be able to go back to having all the methods
be static.

As I look at the classes in the Java API, only a tiny handful of them
have constructors that take a Locale as an argument and only a tiny
handful have setLocale methods. Assuming that the Java API is
considered well-designed by the Java community - and I have to hope it
is :-) - that tells me that the remaining 99.9% of classes are
expecting to provide any locale-specific information in only ONE
Locale.

Furthermore, no class invoking the API is typically going to
want to get the information in more than one language at a go.
Essentially, the classes operate on the basis of the Locale defined by
the user.country and user.language properties. Therefore, if my
properties are set to English and Canada, that is the locale that the
JVM is going to try to find - of course it will settle for other
flavours of English if there is no specific en_CA resource bundle -
and use for any other locale-specific text. (DateFormats,
NumberFormats, and their kin handle the localization needs of those
special kinds of data.)

Providing a way to set a specific Locale and even to change that
Locale on the fly so that classes could potentially invoke the class
repeatedly for different Locales is simply overbuilding and is almost
certainly not necessary at all! (I say 'almost' in deference to Lew's
observations about there being no hard and fast rules, which makes a
lot of sense to me.) So I think I can dispose of Locale in
constructors (and their associated getInstance() methods altogether.
Likewise, I can omit and setLocale() and/or getLocale() methods from
my utility classes too. Methods that seek to get ResourceBundles will
simply seek them for the default Locale, as determined via
Locale.getDefault().