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)
Message-ID: <4B37741C.4080700@oliver-heger.de>
Date: Sun, 27 Dec 2009 15:50:04 +0100
From: Oliver Heger <oliver.heger@oliver-heger.de>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [lang] Generic object factories
References: <4B366546.9060901@oliver-heger.de>
 <4B36A263.2020805@btopenworld.com>
 <94C476C03BFF5E42AC3518FDAC9643C4E2DEBEC33F@HQMAIL.rocketsoftware.com>
In-Reply-To: 
 <94C476C03BFF5E42AC3518FDAC9643C4E2DEBEC33F@HQMAIL.rocketsoftware.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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