Re: Another JUnit scenario
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