Design Questions about static factory classes
in [Java Programming]
|
From: Arne Vajhøj on 22 May 2010 19:40 On 22-05-2010 15:17, Rhino wrote: > Sorry for the off-topic digression but I just can't help but admit to > some surprise that some eastern Europeans still know German. Stalin and > his eastern European brothers were pretty ruthless about exiling or > killing their German residents in the immediate aftermath of WW II. I had > thought the German language was pretty much non-existent in the former > Warsaw Pact area by this point.... Based on what you're saying, it > appears that I was premature in assuming an absence of German in those > countries. There may be few ethnic Germans left in those countries. But there are a lot of people that wants to do business with German companies. Arne
From: Arne Vajhøj on 22 May 2010 19:46 On 22-05-2010 07:17, Tom Anderson wrote: > 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. There are increasing levels of difficulties of internationalization: 1) different language 2) different alphabet 3) different writing directions If #3 does not require code changes, then somebody will have had to planned very well. Arne
From: Arne Vajhøj on 22 May 2010 19:52 On 22-05-2010 15:39, Rhino wrote: > Arne Vajh�j<arne(a)vajhoej.dk> wrote in > news:4bf71c05$0$284$14726298(a)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? Something else. LocalizationFactory lf = new LocalizationFactory(); lf.setLocale(new Locale("FR", "fr")); X x = lf.getX(); Y y = lf.getY(); Z z = lf.getZ(); Arne
From: Lew on 22 May 2010 20:06 Arne Vajhøj wrote: > English is a mix of the languages of the invaders from > Germany, Scandinavia and France. Of course, borrowing from any other language is far from taboo. It's enough to drive you meshugge. Maybe some sleazy gigolo tycoon will fund an opera about a funky zombie vampire who lives in an igloo, wearing a parka and smoking cigars, then runs amok because people won't kowtow to him. "English doesn't borrow from other languages. English follows other languages down dark alleys, knocks them over, and goes through their pockets for loose grammar." - Paraphrased from James D. Nicoll -- Lew
From: Tom Anderson on 23 May 2010 06:55
On Sat, 22 May 2010, Arne Vajh?j wrote: > On 22-05-2010 07:17, Tom Anderson wrote: >> 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. > > There are increasing levels of difficulties of internationalization: > 1) different language > 2) different alphabet > 3) different writing directions > > If #3 does not require code changes, then somebody will have had > to planned very well. True. Everyone involved would, i think, be prepared to accept a redeploy when we add RTL languages, or even ideographics. We'll also need to push new versions whenever we roll out to countries which require more significant structural changes - adding new country-specific behaviour to the checkout flow for example (eg ISTR that in some middle eastern countries the law requires that customers must give their national ID number when buying anything online). But it's nice to be able to push out new locales to existing countries (eg adding danish to Denmark, which currently only has english) without a redeploy, and it's absolutely essential to be able to push changed content to an existing locale without taking down the system. tom -- One horse laugh is worth a thousand syllogisms. -- H. L. Mencken |