Design Questions about static factory classes
in [Java Programming]
|
From: Arne Vajhøj on 21 May 2010 19:49 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. 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.. > 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. Arne
From: Arne Vajhøj on 21 May 2010 19:54 On 21-05-2010 16:28, Tom Anderson wrote: > On Fri, 21 May 2010, Rhino wrote: >> 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. > > I strongly disagree. Text for the consumption of end-users should be > localised; text for the consumption of programmers and sysops should not > be. I think the advantages of having a common language for these things > outweight the disadvantages of most people not having them in their > first language. It's like air traffic control - it's vital for clear > communication that i can say "i'm getting the NoMoreJam error", and not > draw a complete blank with French acquaintances who've only ever seen > NYAPlusDeConfiture and Americans familiar with NoMoreJelly. Having a > single language makes googling with error messages and so on a lot more > productive, too - and that's a benefit to the speakers of minor > languages, who have access to squillions of English search results. I would expect developers, testers and operators to understand English too, but unfortunately it is not uncommon for customers to require internationalization for operations. In Europe both Germany and France often require that. Scandinavia not so often. > Of course, being a native english speaker, i would say that, wouldn't it? The argument for a common language is still valid, but you may have a problem if the language chosen was french. >> 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: > > Look up 'resource bundles'. They're the standard way of producing > localised messages, and are absolutely what you should use here if you > really want to do this. They use the current locale, so they leave the > onus of setting that correctly on your developers - but they only need > to set it once for the whole VM, and then messages everywhere come out > in the right language. And those who see the world my way and don't want > localised messages can set it to the canonical standard locale - en_GB. For the text then resource bundles should be the solution, but there are a lot more to internationalization than just text. Arne
From: Arne Vajhøj on 21 May 2010 20:13 On 21-05-2010 19:16, Rhino wrote: > Tom Anderson<twic(a)urchin.earth.li> wrote in And those who see the world my way and don't >> want localised messages can set it to the canonical standard locale - >> en_GB. >> > Sorry, I though it en_US was the canonical standard ;-) I say that as a > Canadian, just to show that I'm not trying to push my own variant of > English :-) Give the state of US and UK software industry then I think we can say it is. And my guess is that Tom meant US English. > I'm very familiar with resource bundles at a detail; I use them quite > frequently. I'm not quite clear on the "big picture" though. I lack any > significant real-world experience with how "multilingual" systems are > written with Java. For instance, if I were a developer whose native > language was French would I typically install a French-language JVM, read > the Java API in French, and write my system so that it never chose or > changed Locales? Would my classes simply make use of the Resource > Bundles I had written in French and would I leave it up to foreign > purchasers of my system to simply translate the ResourceBundles for their > own languages? I think it depends a lot of the context you develop software in. Global or local development? global => do development in English local => pick English or local language as you prefer Are you developing single-customer project-style software or multi-customer product-style software? product => internationalize, have English and then add to supported languages as customers require them (note that customers can want 3 things A) English version, B) local version C) Choice of English for local for end users project => whatever the customer wants And then we have not even talked about interesting countries like Belgium and Switzerland with multiple official languages (Canada is easier because one of the languages is English). That is not a clear answer, but it is a complex question! > Also, is there much need for systems in which the user can switch > languages on the fly? In other words, let's say I'm working in a system > that uses French language ResourceBundles but am finding that the French > is not to my liking - maybe it's Quebecois instead of Parisian - and I > realize that I will understand better in my second language, English, > which I learned by watching MTV. Would a system typically have the > capability of letting the user invoke a switch to another language via > setLocale()? See above. Customer is king. > Or would I install an English-language JVM and run my system > on that? > Hold on, that doesn't quite make sense. I don't recall any language > selection option any time I've installed Java. The language of the JVM > comes from a system property which I can presumably change. Hmm, I wonder > if I should take a minute and switch my language to see what kind of > output I get from core Java classes. Will the message that comes with my > Exception be in the newly-chosen language?.... I should answer this > question for myself with a bit of experimentation.... That problem is not so important. You would not want to display Java exception text to end-users anyway. Arne
From: Tom Anderson on 22 May 2010 06:55 On Fri, 21 May 2010, Arne Vajh?j wrote: > On 21-05-2010 19:16, Rhino wrote: >> Tom Anderson<twic(a)urchin.earth.li> wrote in > And those who see the world my way and don't >>> want localised messages can set it to the canonical standard locale - >>> en_GB. >>> >> Sorry, I though it en_US was the canonical standard ;-) I say that as a >> Canadian, just to show that I'm not trying to push my own variant of >> English :-) > > Give the state of US and UK software industry then I think we can say it > is. > > And my guess is that Tom meant US English. Certainly not! en_GB is the canonical form, and en_US is merely a popular but subordinate deviation. tom -- They entered the Vortex and the dreams became reality
From: Tom Anderson on 22 May 2010 07:17
On Fri, 21 May 2010, Rhino wrote: > I'm very familiar with resource bundles at a detail; I use them quite > frequently. I'm not quite clear on the "big picture" though. I lack any > significant real-world experience with how "multilingual" systems are > written with Java. For instance, if I were a developer whose native > language was French would I typically install a French-language JVM, > read the Java API in French, and write my system so that it never chose > or changed Locales? Would my classes simply make use of the Resource > Bundles I had written in French and would I leave it up to foreign > purchasers of my system to simply translate the ResourceBundles for > their own languages? If you were French, you might. But in general, i don't think there's any correlation between the languages of the system and of its developers. A French developer might well have his machine's locale set to fr_FR, and he might well read documentation in french (if there is such a thing - i've seen some Sun documentation translated into japanese, but rarely into European languages other than english), but he ought to have his JVM set to run in one of the languages the system is being built for, and he ought to routinely test it in other such languages. For instance, i'm currently on a project which will roll out to 23 countries in the first wave. They're all European and North Amererican, and in a slightly weird twist, to begin with we're only supporting english, french, and german as languages. So, if you're a native of the UK, the US, Canada, France, Switzerland, Luxembourg or a few other places, you have your own language, but if you live in Hungary or the Netherlands, you'll have to be able to read english, or in some cases in eastern Europe, german. In the second wave, Korea will be added, and for that, there will be korean. I assume that in later waves, there will be proper localisation into national languages, but i haven't heard about that. By that point, such localisation would not require programmer input (or at least only a tiny bit) - the client's content management team will be able to add new locales and their corresponding translations to the system themselves. We're keeping translations in a database rather than resource bundle files, so they can do this to a running system without having to modify the codebase. Anyway, we're British, the client's programmers are American (well, they're in America, and are either American or Indian), the contractors we had involved a while ago were Indian (a mix of hindi, telugu and malayalam speakers), and the client's HQ, including their infrastructure guys and the virtual machines where we all work, is in Denmark. We all work in english. I think the JVM default locale is en_US throughout. So, a daily feature of our project is an Indian programmer in an office in the US using a machine in Denmark to look at content in german which will be shown to customers in the Czech Republic. I have no idea if any of this answers your question. > Also, is there much need for systems in which the user can switch > languages on the fly? In other words, let's say I'm working in a system > that uses French language ResourceBundles but am finding that the French > is not to my liking - maybe it's Quebecois instead of Parisian - and I > realize that I will understand better in my second language, English, > which I learned by watching MTV. Would a system typically have the > capability of letting the user invoke a switch to another language via > setLocale()? Or would I install an English-language JVM and run my > system on that? I wouldn't expect to have to install a second JVM. I also wouldn't expect to be able to change locale on the fly - i might try it, but i wouldn't be surprised if it didn't work. I would expect that i'd be able to get what i wanted by killing the system and restarting with the following parameters added to the java command line (assuming a Sun java): -Duser.language=en -Duser.country=GB > Hold on, that doesn't quite make sense. I don't recall any language > selection option any time I've installed Java. The language of the JVM > comes from a system property which I can presumably change. Hmm, I > wonder if I should take a minute and switch my language to see what kind > of output I get from core Java classes. Will the message that comes with > my Exception be in the newly-chosen language?.... I should answer this > question for myself with a bit of experimentation.... Experimentation is often a very good thing to do. tom -- They entered the Vortex and the dreams became reality |