Design Questions about static factory classes
in [Java Programming]
|
From: Rhino on 23 May 2010 17:18 Arne Vajh�j <arne(a)vajhoej.dk> wrote in news:4bf86e26$0$282$14726298(a)news.sunsite.dk: > 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(); > That seems pretty much the same as Approach 2 to me, except that the class is called LocalizationFactory instead of LocalizationUtils. Am I missing something? Is it considered a best practice to put Factory in the name of a utility class that uses static getInstance() methods and private constructors? If so, I have no problem doing that. -- Rhino
From: Rhino on 23 May 2010 17:33 Tom Anderson <twic(a)urchin.earth.li> wrote in news:alpine.DEB.1.10.1005222231170.8422(a)urchin.earth.li: > On Sat, 22 May 2010, Rhino wrote: > >> Tom Anderson <twic(a)urchin.earth.li> wrote in >> news:alpine.DEB.1.10.1005221156210.12091(a)urchin.earth.li: >> >>> 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. >> >> Sorry for the off-topic digression but I just can't help but admit to >> some surprise that some eastern Europeans still know German. > > Hey, don't look at me. I got the list of locales handed to me from > someone else, and he got it from someone else, and i assume that > someone who knew what they were doing drew it up. Or at least, i hope > so; all i can assume is that someone who had the authority to do it > did it. > >>> 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. >> >> What codebase changes concern you? If you do ResourceBundles >> correctly, there really aren't any code changes. You simply throw >> ResourceBundles for the appropriate languages into the jar and you >> should be good to go, right? > > And then deploy the JAR and reboot. Not so hot if you're hoping to run > a global ecommerce site. > I didn't realize you needed to reboot to get the new Jar to take effect. That's lousy. Isn't it possible to simply refresh the new Jar in place without rebooting? I'm pretty sure Tomcat lets you redeploy a Jar without stopping Tomcat first but my Tomcat skills are rusty so I may be wrong.... >> Do your classes have constructors (or getInstance() methods that >> establish a Locale? Do you have setLocale() methods in your classes? >> If you don't use either approach, how do you set the Locale and how >> do you change it if it needs to be changed? > > The system is a web application. We attach a locale to each user > session. We have a component near the top of the servlet container's > request processing chain that looks at the incoming request, and the > existing user object if there is one, and sets the locale accordingly. > When a class needs to know the current locale, it gets hold of the > user object for the current request (via some sort of thread-local > variable or some such) and asks it. So, no class inside the system has > any concept of its own locale - they always use the 'current locale', > where that's something that can be different in different threads that > are running at the same time. > I see. That sounds like a pretty reasonable design for your needs. -- Rhino
From: Rhino on 23 May 2010 17:40 Arne Vajh�j <arne(a)vajhoej.dk> wrote in news:4bf86b7c$0$281$14726298(a)news.sunsite.dk: > 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. > Oh! So applications are being deployed in German because the locals will be communicating with head office in German, not because the locals are German speakers! I hadn't considered that possibility. It makes sense though; some of the Slavic countries still educate some of their people in the German language despite their very bad memories of Hitler and WWII. I took a short Russian course once and the teacher, a native Russian, had also studied German quite extensively. Also, I seem to remember a Pole telling me that Russian, which used to be mandatory in Polish schools during the Cold War, has now been made optional and many students are choosing to study German and other languages instead. I suppose the eastern Europeans will take advantage of those students to work with your system in German while they await eventual translation to Hungarian, Polish or whatever.... -- Rhino
From: Martin Gregorie on 23 May 2010 17:40 On Sun, 23 May 2010 21:29:11 +0000, Rhino wrote: > > Foreign language error messages are going to be a lot harder though. > It's not going to be apparent that "Floomba patixet snarblot" means > "Please enter password" ;-) Unless every error message contains a > visible message number like "XYZ123 Floomba patixet snarblot"; then you > just look up XYZ123 (assuming that's a unique message number) and then > find that same message in your English ResourceBundle. > > A little tedious for sure but workable in a pinch. Or, you can spend > time and money finding someone who knows English and the local language. > Mind you, I would like to think that at least some of the better > educated people in the local office speak both the local language and > English moderately well, possibly well enough to get the essence of the > problem fairly directly.... > I think you'll find that this is precisely the reason why DEC (while they existed) and IBM tend to put such ugly prefixes on all their error messages. Its also easy to go further: given such tags its easy to support centre software to take a trace etc. from a site anywhere in the world and and make it understandable to the support guy no matter what language he speaks. If you're supporting a multi-language application then IMO such a translation package should automatically be a part of the project. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
From: Arne Vajhøj on 23 May 2010 18:02
On 23-05-2010 17:40, Rhino wrote: > Arne Vajh�j<arne(a)vajhoej.dk> wrote in > news:4bf86b7c$0$281$14726298(a)news.sunsite.dk: > >> 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. >> > Oh! So applications are being deployed in German because the locals will be > communicating with head office in German, not because the locals are German > speakers! I hadn't considered that possibility. It is more like: - people learn German for commercial reasons - the software offers a few languages but not the native language - they pick German because the prefer that over the other alternatives Very few apps support all European languages. It is rather common to support English, Spanish, French and German. And let the users pick the one they understand best. Arne |