[lang] Generic object factories

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[lang] Generic object factories

Oliver Heger-3
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Generic object factories

Ted Dunning
This interface seems so generic as to be difficult to understand what the
motivation is.

I can see the point of a one method interface like Comparable, but how does
ObjectFactory<T> help?  Is your goal documentation?  Name standardization?
Reflection marker?

On Sat, Dec 26, 2009 at 11:34 AM, Oliver Heger <[hidden email]
> wrote:

> public interface ObjectFactory<T> {
>    T create();
> }
> Does this make sense?




--
Ted Dunning, CTO
DeepDyve
Reply | Threaded
Open this post in threaded view
|

Re: [lang] Generic object factories

Valery Silaev
Let me draw an analogy with Adoby Flex:

There is an IFactory interface that servers for the same purpose and is
quite useful.

The problem it solves is the following:
Typically (in Flex) object initialization is not only constructor
invocation, but also setting certain properties and invoking different
init/setup-like methods.

I would say this is a case for Java too, so having ObjectFactory interface
makes sense for me -- it's used to define a contract to return fully
configured objects when configuration is more complex than just constructor
invocation.

Regards,
Valery Silaev


On Sat, Dec 26, 2009 at 10:22 PM, Ted Dunning <[hidden email]> wrote:

> This interface seems so generic as to be difficult to understand what the
> motivation is.
>
> I can see the point of a one method interface like Comparable, but how does
> ObjectFactory<T> help?  Is your goal documentation?  Name standardization?
> Reflection marker?
>
> On Sat, Dec 26, 2009 at 11:34 AM, Oliver Heger <
> [hidden email]
> > wrote:
>
> > public interface ObjectFactory<T> {
> >    T create();
> > }
> > Does this make sense?
>
>
>
>
> --
> Ted Dunning, CTO
> DeepDyve
>
Reply | Threaded
Open this post in threaded view
|

RE: [lang] Generic object factories

Gary Gregory
In reply to this post by Oliver Heger-3
Can you give some concrete examples?

Also, nit-picking on the name, since everything that is created IS an Object, having "Object" in the name is redundant IMO. This says the same:

public interface Factory<T> {
      T create();
}

Gary

> -----Original Message-----
> From: Oliver Heger [mailto:[hidden email]]
> Sent: Saturday, December 26, 2009 11:35
> To: Commons Developers List
> Subject: [lang] Generic object factories
>
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Generic object factories

Benson Margulies
Please pick another name, whatever else you do. JAXB uses ObjectFactory.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Generic object factories

Stephen Colebourne
In reply to this post by Oliver Heger-3
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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: [lang] Generic object factories

Gary Gregory
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:[hidden email]]
> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Generic object factories

Oliver Heger-3
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:[hidden email]]
>> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Generic object factories

James Carman
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
<[hidden email]> 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:[hidden email]]
>>> 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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [lang] Generic object factories

Matt Benson-2
In reply to this post by Gary Gregory
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:[hidden email]]
>> 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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]