Design Questions about static factory classes
in [Java Programming]
|
From: Lew on 22 May 2010 16:12 Lew wrote: >>>> It has ever amazed me how well the Brits speak English. Awesome! Mike Schilling wrote: >>> Some of them even write it well, though rarely as well as the Irish. Tom Anderson wrote: >> And of course, it's the Scandinavians who are the real masters of it. Mike Schilling wrote: > I was thinking of Shaw, Wilde, Joyce, Synge, and Yeats. Samuel Beckett, Jonathan Swift. -- Lew
From: Lew on 22 May 2010 16:17 Lew wrote: >>> Why do you want to provide factory classes at all? Rhino wrote: >> (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? Eric Sosman wrote: > He probably isn't. Factory methods are quite common; factory He saw my amendment that I meant factory methods, not classes. > *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.) I did not "change my mind", nor do I recommend the use of factory methds willy-nilly. But I did not make a recommendation in my question, I asked a question. Why are you providing factory methods at all? There are reasons to provide a factory method. They do not always apply. What are your reasons? Just answer the question. -- Lew
From: Tom Anderson on 22 May 2010 17:38 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. > 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. tom -- build the roof with holes in
From: Arne Vajhøj on 22 May 2010 19:33 On 22-05-2010 14:20, Rhino wrote: > Lew<noone(a)lewscanon.com> wrote in news:ht8s6u$o4h$1(a)news.albasani.net: >> Arne Vajhøj wrote: >>>> And my guess is that Tom [sic] meant US English. >> >> Tom Anderson wrote: >>> Certainly not! en_GB is the canonical form, and en_US is merely a >>> popular but subordinate deviation. >> >> It has ever amazed me how well the Brits speak English. Awesome! > > Yeah, you'd think they invented the language or something ;-) English is a mix of the languages of the invaders from Germany, Scandinavia and France. Arne
From: Arne Vajhøj on 22 May 2010 19:38
On 22-05-2010 15:05, Rhino wrote: > Arne Vajh�j<arne(a)vajhoej.dk> wrote in >> 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! >> > It certainly is. I'm trying to write code that will be easily usable by > non-English speakers. But my code isn't actually being written for a > specific customer at this time, other than me. At the moment, I'm trying > to put together a sort of code portfolio. I'm hoping it will show > prospective employers or clients that I am culturally sensitive enough to > write code that will work in multiple languages and knowledgeable on how > to do it. In other words, I don't just want to claim that I am culturally > sensitive but then have no code to back that up. When they challenge me > to prove that I can write code that works for customers in various > locales, I want to be able to point them to some decent examples where I > have done that. I'm just trying to figure out the best way to do that > right now..... Do you just want to support western languages? Or do you also want to solve the difficult problems? >> That problem is not so important. You would not want to display >> Java exception text to end-users anyway. >> > Really? I find that a surprising thing to say. Maybe we're not talking > about the same thing. > > I'm thinking of a situation like completing a form in a GUI. The customer > has to enter his date of birth. Let's say that I can't use a JSpinner for > some reason; it can't do everything I need it to do. The customer is > given a simple JTextField for entering a date. Clearly, the customer > would have many opportunities to enter bad data. He could type in 1985- > 15-31 when he meant to type 1985-05-01; the first value is obviously a > bad date since there are only 12 months in the year, not 15. My practice > is to write edits that check for that kind of mistake and generate an > exception, typically IllegalArgumentException, with a clear error message > that reminds the user that there is no such month as '15'. Naturally, the > customer might not be an English speaker so I put all such messages in > ResourceBundles so that other bundles can easily be added for any > languages that I support. > > How would you handle such a situation? Catch the exception but display something else that the exception text. Exceptions texts are for log files to be handed over to developers. For user input I don't even think that you should throw an exception. Maybe just test and tell the user to correct. Bad user input is not really exceptional enough to justify an exception. Arne |