Instantiating a class based on a generic type

[Downturn]

I'm not sure if this is possible, or even a very good idea, but here's
what I'm trying to accomplish.

I have a top level interface, InterfaceMain. Then I have a bunch of
interfaces that extend InterfaceMain. Now, I've got another interface,
InterfaceCollection, which extends the java.util.Collection interface
(doesn't add anything, it's just there for typing purposes).
InterfaceCollection is generic, though what I really want is for
InterfaceCollection to be used for anything that implements
InterfaceMain or any interface that extends InterfaceMain.

So then I have a bunch of classes that implement one of the interfaces
that extend InterfaceMain, and I have a class that is to implement
InterfaceCollection.

This all seems rather straightforward so far except that the elements
that will be in a collection of InterfaceCollection aren't actually
instantiated until that specific entry is to be returned via
Iterator.next(). The problem I'm having is trying to figure out which
one of the implementation classes to instantiate based on the type of
the generic that the InterfaceCollection class was instantiated with.

I'll try to explain in a slightly different way that may help:

Read this as kind of an inheritance tree:

InterfaceMain
|
--- InterfaceA
|
--- InterfaceB
|
--- InterfaceC

InterfaceCollection
|
--- InterfaceCollectionImplA

InterfaceAImpl implements InterfaceA
InterfaceBImpl implements InterfaceB
InterfaceCImpl implements InterfaceC

// Assume getCollection() creates an instance of
InterfaceCollectionImplA
InterfaceCollection<InterfaceB> collectionObject = getCollection();

--------------

So now I've got an instance InterfaceCollectionImplA instantiated with
the generic type InterfaceB as collectionObject. As I said above, the
elements in collectionObject have not yet been instantiated. However,
when collectionObject was instantiated it was essentially given a list
of the objects that are part of its collection, so it has the data
necessary for the objects that should be instantiated on the fly.

Now, trying to implement the Iterator is what's killing me. The
Iterator is supposed to instantiate the right instance of the
implementation class (InterfaceAImpl, InterfaceBImpl, or
InterfaceCImpl) based on the interface used as the generic type, in
this case InterfaceB, so it should be instantiating InterfaceBImpl.

Is it possible to determine in InterfaceCollectionImplA what interface
was used for the generic value (InterfaceA, InterfaceB, or InterfaceC)
and then based on that instantiate the correct implementation class
(InterfaceAImpl, InterfaceBImpl, InterfaceCImpl)? Is this really even
that great of an idea? Should I be doing something completely
different?

I hope I've done a decent job of explaining the problem.

Thanks very much.

Matt

 

[Downturn]

I've kind of decided that based on erasure that it isn't possible. Oh
well.

 

[ballpointpenthief]

I'm not sure if this is possible, or even a very good idea, but here's
what I'm trying to accomplish.

Is an Abstract Factory Pattern anything like what you're trying to do?

I have a top level interface, InterfaceMain. Then I have a bunch of
interfaces that extend InterfaceMain. Now, I've got another interface,
InterfaceCollection, which extends the java.util.Collection interface
(doesn't add anything, it's just there for typing purposes).
InterfaceCollection is generic, though what I really want is for
InterfaceCollection to be used for anything that implements
InterfaceMain or any interface that extends InterfaceMain.

Now, trying to implement the Iterator is what's killing me. The
Iterator is supposed to instantiate the right instance of the
implementation class (InterfaceAImpl, InterfaceBImpl, or
InterfaceCImpl) based on the interface used as the generic type, in
this case InterfaceB, so it should be instantiating InterfaceBImpl.

Is this a good idea? - If your Iterator is doing more than iterating
then maybe it isn't an Iterator...

<snip...

 

[The Billboard Hot 100]

I think u probably know but I want to tell you that maybe you might
need to use the "instanceof" operator somewhere in the class before
iteration!

Cheers!!

 

[a24900]

I'm not sure if this is possible, or even a very good idea,

It is not a good idea, even if it would work.

You are trying to be all-too clever. While doing so you are creating a
maintenance nightmare for those programmers having to work on the code
after you. Maybe even for yourself. Too many types, too many pattern
implementations and trying to push Generics to the limit is never a
good idea. It is what made C++ templates such a nightmare (STL my
arse ...), and it is why Java Generics deserve to die. It encourages
programmers trying to be too clever.

From that point of view it really doesn't matter if it can be made to

work or not. You are already having problems to present and explain
your architecture. You try two time, maybe you already feel it is
FUBAR and weren't sure your first explanation works.

 

[Downturn]

Is an Abstract Factory Pattern anything like what you're trying to do?

Yes.

Is this a good idea? - If your Iterator is doing more than iterating
then maybe it isn't an Iterator...

In some ways I see your point. I think this is probably a case of
"pre-optimization" in that I'm trying to delay hitting the database
(which is what is all behind this code) until I actually have to. The
iterator goes over an initial query and the actual query for data
doesn't come until later. Whether I actually need to do this is
certainly a good question because, as I said, this is a case of
possibly unnecessary (and misguided) "pre-optimization". I plan to toy
with different ideas and see what works best, but this just happens to
be the idea I was currently working on.

work or not. You are already having problems to present and explain
your architecture. You try two time, maybe you already feel it is
FUBAR and weren't sure your first explanation works.

No matter how simple something is, it's best to always try to explain
it multiple ways. Not saying that you are wrong about the architecture
possibly being fubar'd, merely noting that multiple explanations does
not necessarily imply failure.

Anyway, I stopped trying to be so clever with reflection on the
generics. It's perfectly possible (and very easy) for me to know ahead
of time which impl classes to instantiate. I was just trying to be
clever with reflection so I wouldn't have to pass that information
around separately. And I suppose being clever isn't always such a good
idea when it can introduce too much indirection.

Thanks for the responses and suggestions.

Matt