Another JUnit scenario
in [Java Help]
|
Prev: Design Questions about static factory classes
Next: JavaSE/EE + Tomcat 6 + Windows service on 64 bit
From: Lew on 23 May 2010 10:27 On 05/23/2010 10:25 AM, Lew wrote: > Remember, the only hard and fast rule of programming is that there are > no hard and fast rules of programming. I posted this in the wrong thread - should've been in "Design Questions about static factory classes". Seems that a hard and fast rule about my posts is that I realize my mistake just after pressing Send. -- Lew
From: Rhino on 23 May 2010 14:40 Lew <noone(a)lewscanon.com> wrote in news:htbds9$c5r$1(a)news.albasani.net: > On 05/23/2010 10:03 AM, Rhino wrote: >> Just to be clear, let's say that the class containing my >> displayLocales() method is called LocalizationUtils and it is a >> static factory class. Are you saying that the stream or writer or >> whatever should be configured in the constructor of LocalizationUtils >> or in the class which CALLS LocalizationUtils? I'm assuming you mean >> the latter but I just want to be sure. > > He was saying in the constructor of LocalizationUtils. However, > static factory classes have their own rules. > > A (usually - always the disclaimer) better pattern is to include the > Locale as an argument to the factory method. Static state is an > antipattern. > > public class LocalizationUtils > { > /** Don't forget the private constructor! */ > private LocalizationUtils(){} > > /** > * Foo factory with default Locale. > * @return Foo instance with default Locale. > */ > public static Foo getFooInstance() > { > return new SubtypeOfFoo(); > } > > /** > * Foo factory with custom Locale. > * @param locale custom Locale. > * @return Foo instance with custom Locale. > */ > public static Foo getFooInstance( Locale locale ) > { > return new SubtypeOfFoo( locale ); > } > } > > Remember, the only hard and fast rule of programming is that there are > no hard and fast rules of programming. > (I saw your note that you meant to put this in the other thread. I hope you'll still look back here for my followup though....) I'm REALLY getting confused now. Do you mean for Foo to be the constructor for the stream or writer that Daniel suggested? And why would a non-default Locale call for a subtype of Foo, rather than Foo itself?? I was looking at the source code for the Properties class, specifically the list() methods (I finally took a minute to find out where the source code in the Java API is again) and I didn't see any contructors for writers or streams in there. Is Properties not a good class to imitate for my situation then? -- Rhino
From: Patricia Shanahan on 23 May 2010 15:02 Rhino wrote: .... > I was looking at the source code for the Properties class, specifically > the list() methods (I finally took a minute to find out where the source > code in the Java API is again) and I didn't see any contructors for > writers or streams in there. Is Properties not a good class to imitate > for my situation then? .... In general, you should not imitate classes, such as Properties, that were designed very early in the life of Java. Many of them suffer from at least one of two problems: 1. The initial Java API writers may have been very smart, but the collective learning of the Java community over the years has often led to better techniques. In particular, they tend to depend too much on inheritance, rather than composition. Making Properties extend Hashtable creates problems. 2. They are limited in their use of features added to the language since they were defined. Even if one were to expose the map aspects of Properties, it would have been defined to implement Map<String,String>, rather than extend Hashtable, if the Map interface and generics had existed when it was defined. The Map optional methods that are undesirable for Properties, put and putAll, would have thrown UnsupportedOperationException. Patricia
From: Lew on 23 May 2010 15:53 Lew wrote: >> A (usually - always the disclaimer) better pattern is to include the >> Locale as an argument to the factory method. Static state is an >> antipattern. >> >> public class LocalizationUtils >> { >> /** Don't forget the private constructor! */ >> private LocalizationUtils(){} >> >> /** >> * Foo factory with default Locale. >> * @return Foo instance with default Locale. >> */ >> public static Foo getFooInstance() >> { >> return new SubtypeOfFoo(); >> } >> >> /** >> * Foo factory with custom Locale. >> * @param locale custom Locale. >> * @return Foo instance with custom Locale. >> */ >> public static Foo getFooInstance( Locale locale ) >> { >> return new SubtypeOfFoo( locale ); >> } >> } >> >> Remember, the only hard and fast rule of programming is that there are >> no hard and fast rules of programming. Rhino wrote: > I'm REALLY getting confused now. Do you mean for Foo to be the > constructor for the stream or writer that Daniel suggested? And why would No. I mean for some subtype of 'Foo', possibly 'Foo' itself, to be the actual type of the constructed instance, regardless of whether you specify the 'Stream' or 'Locale' or any other attribute. > a non-default Locale call for a subtype of Foo, rather than Foo itself?? 'Locale' or 'Stream' or any other attribute for which the factory is responsible, the principles are the same. What makes you think that the non-default 'Locale' setting has anything to do with using a subtype? I showed use of a subtype in both cases. If you are only constructing 'Foo' instances and never different implementors of 'Foo', you probably don't need a factory class and should just use 'Foo' constructors. One of the main purposes of a factory class is to provide a hidden implementation of the constructed type. The returned type in such cases is nearly always an interface. You never answered my question about why you wanted to use a static factory method, let alone a factory class, in the first place. The question was neither arbitrary nor insignificant. -- Lew
From: Arne Vajhøj on 23 May 2010 19:03
On 23-05-2010 10:25, Lew wrote: > On 05/23/2010 10:03 AM, Rhino wrote: >> Just to be clear, let's say that the class containing my displayLocales() >> method is called LocalizationUtils and it is a static factory class. Are >> you saying that the stream or writer or whatever should be configured in >> the constructor of LocalizationUtils or in the class which CALLS >> LocalizationUtils? I'm assuming you mean the latter but I just want to be >> sure. > > He was saying in the constructor of LocalizationUtils. However, static > factory classes have their own rules. > > A (usually - always the disclaimer) better pattern is to include the > Locale as an argument to the factory method. Static state is an > antipattern. > > public class LocalizationUtils > { > /** Don't forget the private constructor! */ > private LocalizationUtils(){} > > /** > * Foo factory with default Locale. > * @return Foo instance with default Locale. > */ > public static Foo getFooInstance() > { > return new SubtypeOfFoo(); > } > > /** > * Foo factory with custom Locale. > * @param locale custom Locale. > * @return Foo instance with custom Locale. > */ > public static Foo getFooInstance( Locale locale ) > { > return new SubtypeOfFoo( locale ); > } > } > > Remember, the only hard and fast rule of programming is that there are > no hard and fast rules of programming. I would prefer a non static field + getter + setter in the factory over the arguments to the get instance methods. IF you need to get many objects different places in the code then configuring the factory once may require less code and may work better if the factory is retrieved via something like Spring. Arne |