Unless [lang] would use it internally all over the place. Is there a case for that? How is the interface useful without parameters?
Gary > -----Original Message----- > From: Stephen Colebourne [mailto:scolebou...@btopenworld.com] > Sent: Saturday, December 26, 2009 15:55 > To: Commons Developers List > Subject: Re: [lang] Generic object factories > > Once upon a time, there was a commons sandbox project that held all > sorts of small interfaces just like this one. It was called commons- > pattern. > > It didn't suceed, because these interfaces really need to be provided > by > the JDK and implemented by all the JDK classes to be successful. Beyond > that, it turned out to be better to have domain specific interfaces. > > Thus, I would recommend stronlgy against having this in [lang]. Today, > [functor] and [collections] are the right places for this in commons - > [lang] doesn't have the necessary domain to back it up. > > Stephen > > > Oliver Heger wrote: > > With Java 1.5 it is possible to define a generic interface for > creating > > an object: > > > > public interface ObjectFactory<T> { > > T create(); > > } > > > > This is a proposal to add such an interface to [lang] 3.0 with a > couple > > of default implementations, e.g. > > - a ConstantObjectFactory returning always the same constant object, > > - a ReflectionObjectFactory which creates new instances of a given > class > > using reflection > > > > Some Initializer classes in the concurrent package also deal with the > > creation of objects. They could implement this interface, too. > > > > Client classes that use this interface to create dependent objects > would > > be pretty flexible. By specifying concrete factory implementations it > is > > easy to configure the concrete objects they use and how they are > created > > as well. > > > > Does this make sense? > > Oliver > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
