Design Questions about static factory classes
in [Java Programming]
|
From: Arne Vajhøj on 23 May 2010 18:06 On 23-05-2010 17:18, Rhino wrote: > 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? Maybe not. I just wanted to make sure that the Local could be set once (either constructor or setter) instead of multiple times in the get instance methods or set methods on the individual objects. > 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. I would tend to put factory in the name of a factory class. It describes what it does. Util more indicates a utility method = a method that does something that the calling code could do in multiple lines, but has been centralized in a method. Arne
From: Arne Vajhøj on 23 May 2010 18:07 On 23-05-2010 18:06, Arne Vajh�j wrote: > On 23-05-2010 17:18, Rhino wrote: >> 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? > > Maybe not. > > I just wanted to make sure that the Local could be set once (either > constructor or setter) instead of multiple times in the get instance > methods or set methods on the individual objects. > >> 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. > > I would tend to put factory in the name of a factory class. It > describes what it does. > > Util more indicates a utility method = a method that does > something that the calling code could do in multiple lines, > but has been centralized in a method. And X, Y and Z obviously does not have private constructors, because then LocalizationFactory could not instantiate them. Arne
From: Arne Vajhøj on 23 May 2010 18:35 On 23-05-2010 17:33, Rhino wrote: > Tom Anderson<twic(a)urchin.earth.li> wrote in >> 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.... If you can discard the classloader, then you can do that instead of restarting the JVM. But it is still an interruption of production. In tomcat that is what happens when you restart just the app and not the entire server. Arne
From: Lew on 23 May 2010 19:13 Rhino wrote: >> "Floomba patixet snarblot" Klaatu barada nikto! -- Lew
From: Rhino on 23 May 2010 20:13
On May 23, 7:13 pm, Lew <no...(a)lewscanon.com> wrote: > Rhino wrote: > >> "Floomba patixet snarblot" > > Klaatu barada nikto! > > -- > Lew The Day the Earth Stood Still.... :-) |