Java generics and design patterns: not parameterizing a reference to a generic type is always a bad thing?

Question

this question is partially related to my last question.

I have a generic class representing a collection of generic objects:

public interface MyObject<N extends Number>{}

public interface MyCollecion<N extends Number> {
    public foo(MyObject<N> obj)
}

In my design these collections of objects are constructed by a client class (let's call it CollectionBuilder) through an abstract class approach:

public interface AbstractCollectionFactory {
    public abstract <N extends Number> MyCollection<MyObject<N>> createCollection(String collectionType);

}

Generic collections should be constructed this way:

public class CollectionBuilder{
    AbstractCollectionFactory f;
    public void buildDoubleCollection(){

         MyCollection<MyObject<Double>> c = f.<Double>createCell("MyType");
    }
    public void buildIntegerCollection(){...}
}

Ok.Since here all ok. CollectionBuilder is aware of what is the generic concrete type to specify (Double in this case) and can build correctly. I can compile this with no warning and all should work fine.

Now I have a question related both to generics and the design of my program.

I have another class in my application that need to use the collection built by CollectionBuilder (let's call this class UserClass). The UserClass:

1. Doesn't need to know of which particular concrete type are its collection (MyCollection<MyObject<Double>> or MyCollection<MyObject<Integer>>).
2. perform some operations on these collections invoking some methods defined in MyCollection interface.
3. I would not want to add a generic type to it.

In the situation described, is that a bad idea do not parametrize the generic class MyCollection insied UserClass?

public UserClass{
     MyCollection a;  //warning 
     MyCollection<?> b; //no warning

     public method(MyObject o){  //warning
          a.foo(b); //compile       
     }
     public method2(MyObject<?> o){
          b.foo(o); //error do not compile
     }
}

Java compiler always protest with a warning if I don't specify the generic parameter. Anyway from inside UserClass I don't know the concrete parameter (and I would like to don't know it) and even declaring it with "?" don't allow me to call method foo on MyCollection.

So the question are:

1. not parameterizing a reference to a generic type is always a bad thing?
2. if answer at 1 is NO, is this a right situation for not doing it?
3. if answer at 1 is YES, how can I use MyCollection method from inside UserClass without knowing their generic types?
4. Is mine a bad design ?

I hope to have been clear. I've be struggling on this problem from days, and I have no idea. Please help me.

Concord

Answer 1

1. According to the Java compiler, yes. And this answer contains a lot of good points as to why. Personally I disagree in some situations, especially where the use of Class is concerned (like for instance, if you have a Map<Class, Object>). In such cases having to always tack <?> on to the end of "Class" just feels like needless tedium, and does not make the code any more readable.

   The idea of having Class be parameterized based upon what type of Object it is associated with has always felt a bit dubious in the first place, to me. The point of Class is to have a common interface that can be used to obtain information about any Object (ala reflection), regardless of its type.

   But I digress. According to the Java compiler and the implementors of generic types, you should always parameterize your reference, even if you are only using <?>.

2. Not applicable. Though you can always not declare any type information, and then use @SuppressWarnings("unchecked") along with an explicit cast to make the compiler happy.

3. See Bohemian's answer.

4. There's not really enough information to say. Though off the top of my head, I'm not sure what the actual use-case would be for having "a generic class representing a collection of generic objects". Why not just use the collections directly?

Sypher

Ok..I realize my question is a bit general. I avoided to put details because I wanted a general answer on that. To be more precise MyCollection is an n-dimensional lattice of cells. MyObject are cells of a cellular automata model. (@Arnout Engelen could be intersted in these details too). – Concord

Answer 2

There's almost always a way to parameterise your code. In brief, I'd be typing UserClass, like this:

public UserClass <N extends Number> {
     MyCollection<N> c;

     public method(MyObject<N> o){
          c.foo(o);      
     }
} 

Edit
If you're worried about poluting your client code with generics, you can make an abstract typed class and provide non-typed implementations, like this:

public abstract UserClass <N extends Number> {
     MyCollection<N> c;

     public method(MyObject<N> o){
          c.foo(o);      
     }
} 

public class DoubleUserClass extends UserClass<Double> {}

To reduce class bloat, you can put the non-typed classes inside the base class:

public abstract UserClass <N extends Number> {
     MyCollection<N> c;

     public method(MyObject<N> o){
          c.foo(o);      
     }

     public static class DoubleImpl extends UserClass<Double> {}
     public static class FloatImpl extends UserClass<Float> {}
     public static class IntegerImpl extends UserClass<Integer> {}
} 

And use them like this: new UserClass.DoubleImpl() etc

Stoa

thanks for your answer but ok..I know that. But if I do that, even the class the instantiate my UserClass should be aware of the type of N. So N will propagate to almost every class in my project. But I would like to avoid that because non of those classes except CollectionBuilder need to know about N concrete type. am I making some conceptual mistakes if I want to do that? – Concord

@Heisenbug: What I do in that case is make a generic implementation (e.g. UserClass<N>) that implements a non-generic interface (e.g. UserClassable). Then client code that doesn't care about the parameterization can interact with the non-generic interface, but all the code is still strongly typed. – Comedic

@Daniel Pryden: that sounds good. I'll take in consideration, thanks. – Concord

Answer 3

 MyCollection<?> b; 

 public method2(MyObject<?> o){
      b.foo(o); 
 }

If there's a out-of-band guarantee that b.foo(o) is safe, then we need to make this call work. Introduce a helper method

<N extends Number>
void foo(MyCollection<N> collection, MyObject<?> obj)
{
    @SuppressWarnings("unchecked")
    MyObject<N> obj2 = (MyObject<N>)obj;

    collection.foo(obj2);
}

MyCollection<?> b;
void method2(MyObject<?> o){
     foo(b, o); // now works
}

The cast from MyObject<?> to MyObject<N> is safe, due to the out-of-band gaurantee. It is a checked cast in that sense, so we are justified to suppress the warning.

In a real world application it's not rare that we know more about type relations than the language can express; no programmer needs to be apologetic if he knows more about his code than the compiler.

Casting involving generics is a little bit tricky; it's not intuitive how foo(b,o) works.

It is fine to use raw types MyCollection, MyObject to avoid the hassle. Ignore the warning that you shall not use raw type. That's nonsense.

Lianneliao

+1: thanks for your answer too. I know that I can suppress the warning. I wanted to know if doing such a thing was considered a bad practice. I'm trying to improve my Java skill so.. – Concord

Answer 4

It's easy to get carried away with generics. You have to stop somewhere. So no, I don't think not parameterizing a reference to a generic type is always a bad thing. Sometimes the extra effort required to get all the generics exactly right just isn't worth it.

However, it is better to specify generics where possible, of course. In your example, you could add a generic parameter to UserClass as Bohemian suggests.

As for whether your collection is a bad design: the interfaces/infrastructure you're defining here seems overly general. What does MyCollection have that can't be done with simply java.util.List<YourClass>? Is there really a need for a MyObject interface? If you want to 'tag' a certain type of classes, surely you can come up with a more specific description of what makes these objects different from any other Object?

Bierman