Design Questions about static factory classes
in [Java Programming]
|
From: Rhino on 22 May 2010 15:39 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? -- Rhino
From: Rhino on 22 May 2010 15:45 Arne Vajh�j <arne(a)vajhoej.dk> wrote in news:4bf71d0f$0$277$14726298(a)news.sunsite.dk: > 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. > Agreed. I only mentioned text specifically but I have written code that uses List, Text and Message bundles. I know how to use them all. I'm still struggling a bit with the "big picture" stuff though so that's what I'm asking about here. -- Rhino
From: Rhino on 22 May 2010 15:50 Arne Vajh�j <arne(a)vajhoej.dk> wrote in news:4bf7db7f$0$275$14726298(a)news.sunsite.dk: > On 21-05-2010 19:54, Arne Vajh�j wrote: >> 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. > > Which can be a bit problematic when having a global team > that needs to fix bugs related to a GUI in German or > French. > I can imagine! I have a probably oversimplistic view that virtually all of the developers out there have at least a working knowledge of English and frequently much much better command of the language but that may be a little overoptimistic :-) I can easily imagine a developer that has only a fairly weak grasp of English and no knowledge whatever of French or German - maybe an Asian for example - struggling to uncover the meaning of a message that is probably cryptic even to a native English speaker! I know I've seen a number of messages over the years that were (apparently) written by native English speakers that were almost incomprehensible. I can only imagine how hard these were for people whose English is less fluent than mine..... -- Rhino
From: Patricia Shanahan on 22 May 2010 15:57 Rhino wrote: > which is why I'm struggling with this. When there are several ways to do > something, I'm not always clear on how to choose between them.... Have you done much background reading or studying on software engineering ideas such as separation of concerns and design patterns? For research type projects, where the requirements can change very frequently, I tend towards an approach of initially implementing things as simply as possible for the current requirements, but being very willing to refactor. Patricia
From: Eric Sosman on 22 May 2010 15:57
On 5/22/2010 3:32 PM, Rhino wrote: > Lew<noone(a)lewscanon.com> wrote in news:ht766u$dd3$1(a)news.albasani.net: >> [...] >> Why do you want to provide factory classes at all? >> > (I saw your amendment saying you meant factory METHODS in that sentence.) > > Actually, you and/or Eric (and maybe some others) persuaded me to use > factories for my utility methods several weeks back when I was asking > about the best way to set up my StringUtils class. You're not changing > your mind and advising me against that now are you? He probably isn't. Factory methods are quite common; factory *classes* are relatively rare. (You'll learn more about what's what in a few years, when you've saved enough for "Effective Java," but until then you'll just have to take it on faith.) > Agreed. That's exactly what I meant; I just phrased it crudely in an > attempt to be brief. Brevity is the soul of wit. Crudity is the soul of halfwit. (And crudit�s are the life of the party, but I digest. Er, digress.) -- Eric Sosman esosman(a)ieee-dot-org.invalid |