commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <ja...@carmanconsulting.com>
Subject Re: [lang] Generic object factories
Date Sun, 27 Dec 2009 20:54:19 GMT
Commons Proxy has an interface very much like the one you're
suggesting.  I considered using Commons Functor's "Function" interface
instead.

On Sun, Dec 27, 2009 at 9:50 AM, Oliver Heger
<oliver.heger@oliver-heger.de> wrote:
> The idea is related to some classes in the concurrent package that provide
> specific ways to create objects, e.g. lazy creation or creation in a
> background thread. If there was a standard factory interface implemented by
> these classes, client code could directly make use of these enhanced object
> creation facilities without having to be adapted.
>
> In addition, a factory interface would offer all advantages of the factory
> pattern, for instance lose coupling or a better testability.
>
> But I agree with Gary and Stephen that such an interface would have to be
> supported widely by library classes to be successful. This is probably hard
> to achieve. In the case of [lang] I don't see an obvious place where objects
> are created and where this interface could be used.
>
> Oliver
>
> Gary Gregory schrieb:
>>
>> 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:scolebourne@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-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message