True enough that [functor] already contains *Function interfaces that
meet these requirements.
-Matt
On Dec 26, 2009, at 6:10 PM, Gary Gregory wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
