Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
Sender: jcarman@carmanconsulting.com
In-Reply-To: <4B37741C.4080700@oliver-heger.de>
References: <4B366546.9060901@oliver-heger.de>
 <4B36A263.2020805@btopenworld.com>
	<94C476C03BFF5E42AC3518FDAC9643C4E2DEBEC33F@HQMAIL.rocketsoftware.com>
	<4B37741C.4080700@oliver-heger.de>
From: James Carman <james@carmanconsulting.com>
Date: Sun, 27 Dec 2009 15:54:19 -0500
Message-ID: <f2e8eedf0912271254s11ab54bao9b2e517cf81622ed@mail.gmail.com>
Subject: Re: [lang] Generic object factories
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 provid=
e
> 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 obje=
ct
> creation facilities without having to be adapted.
>
> In addition, a factory interface would offer all advantages of the factor=
y
> 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 ha=
rd
> to achieve. In the case of [lang] I don't see an obvious place where obje=
cts
> 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 cas=
e
>> 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> {
>>>> =A0 =A0T 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