Arne Vajh?j<arne@vajhoej.dk> wrote in
news:4bf71c05$0$284$14726298@news.sunsite.dk:
On 21-05-2010 16:12, Rhino wrote:
In the course of developing test cases for some of my classes,
particularly the classes that are static factories, I've developed
some confusion about localization. Basically, I'm trying to figure
out when I want to have separate constructor and getInstance()
methods
First, I hope we can all agree that, in an ideal world, every class
which can produce text output - even if no text is produced per se,
most classed would be capable of producing error messages for
Exceptions - should be written so that it can produce that output
in the languages of the users of those classes. So, if your utility
classes are used in French-speaking countries, text output and/or
error messages will be in French and so forth for other languages.
Now, I know that many developers will not worry about that - after
all, the whole IT field seems to be fairly English-centric - but I
aspire to make all of _my_ classes locale- sensitive.
I think you are too ambitious.
Probably :-)
Not everything need to be internationalized.
Some forms of output are not even possible to internationalize
(especially languages outside of the western countries can
be difficult).
You should focus on the output that is rich (looks good, has
advanced capabilities).
GUI's (both fat client and web) plus print intended for
advanced printers (not line printers).
Drop it for console IO, log files, print for line printers etc..
Some guidelines on when internationalization is appropriate are just
what I need. I appreciate your advice.
Let's say that I want to make a static factory class
locale-sensitive but I don't want to force the user to choose an
explicit locale every time they try to use the class. That suggests
to me that I go one of two ways:
1. Provide two private constructors - one that takes a specified
locale and one that uses the default locale - and two corresponding
public getInstance() methods, one of which takes a specified locale
and one that uses the default locale. Then, if the user is
comfortable with the default locale, they use the constructor that
doesn't have a locale parameter, otherwise, they use the
constructor that has a locale parameter and specify the locale of
their choice.
2. Provide a single private constructor that has no locale
parameter and a corresponding public getInstance() method. Also
provide getLocale() and setLocale() methods so that a user can
instantiate with the single getInstance() method and then use
setLocale() to alter that locale if it is not to his liking.
I thought I'd have a look at the Java API and see what happens
there. I got something of a mixed bag. A handful of classes have
getInstance() methods that take a Locale parameter, suggesting that
they favour Approach 1. A handful of classes have setLocale()
methods, suggesting that they favour Approach 2. However, the vast,
vast majority of the classes have neither suggesting that they are
NOT locale-sensitive and have no capability for changing the Locale
at all.
I prefer #2 with the note that you set Locale on the factory
not on the objects created by the factory.
Sorry? I'm not clear on the distinction you're making in your note.
Are you envisioning that the invoking class do:
LocalizationUtils localizationUtils =
LocalizationUtils.getInstance(new
Locale("FR", "fr));
Map<String, Locale> myLocales = localizationUtils.getLocales();
-OR-
LocalizationUtils localizationUtils =
LocalizationUtils.getInstance(); localizationUtils.setLocale(new
Locale("FR", "fr"); Map<String, Locale> myLocales =
localizationUtils.getLocales();
Or did you mean something else altogether?