Generics and subclassing -- best etiquette

[Sideswipe]

I have come upon this several times and I am just looking for some
discussion on this:

given:

public class MyClass extends SomeClass<String,Object> {

}

which is better:

MyClass x = new MyClass();

SomeClass<String,Object> x = new SomeClass<String,Object>();

MyClass does nothing at all -- that wasn't a mistake above. It merely
declares generic types.


I like that MyClass reduces overall syntax in the code if I use it
multiple times. It also hides some detailing and allows for extra
functionality moving forward -- all while giving me the same typing
checks. But it seems stupid to me to have a file and class that have
no functional code at all. Potentially not even a constructor.

Thoughts?

 

[Arne Vajhøj]

I have come upon this several times and I am just looking for some
discussion on this:

given:

public class MyClass extends SomeClass<String,Object> {

}

which is better:

MyClass x = new MyClass();

SomeClass<String,Object> x = new SomeClass<String,Object>();

MyClass does nothing at all -- that wasn't a mistake above. It merely
declares generic types.

I like that MyClass reduces overall syntax in the code if I use it
multiple times. It also hides some detailing and allows for extra
functionality moving forward -- all while giving me the same typing
checks. But it seems stupid to me to have a file and class that have
no functional code at all. Potentially not even a constructor.

If MyClass does not anything and will not do in the future either, then
I would just use generics directly.

But if SomeClass is "fixed" in functionality and more functionality
could be needed in the future, then a MyClass could make sense.

Arne

 

[hiwa]

I have come upon this several times and I am just looking for some
discussion on this:

given:

public class MyClass extends SomeClass<String,Object> {

}

which is better:

MyClass x = new MyClass();

SomeClass<String,Object> x = new SomeClass<String,Object>();

MyClass does nothing at all -- that wasn't a mistake above. It merely
declares generic types.

I like that MyClass reduces overall syntax in the code if I use it
multiple times. It also hides some detailing and allows for extra
functionality moving forward -- all while giving me the same typing
checks. But it seems stupid to me to have a file and class that have
no functional code at all. Potentially not even a constructor.

Thoughts?

It is mildly criticized at:
http://forum.java.sun.com/thread.jspa?forumID=316&threadID=667720

 

[Mark Rafn]

public class MyClass extends SomeClass<String,Object> { }

which is better:
MyClass x = new MyClass();
SomeClass<String,Object> x = new SomeClass<String,Object>();

Better for what purpose? I might prefer either one depending on what I'm
doing. It's a little clearer if you use a more concrete example. Contrast:
Pair<Object,Long>
class ResultAndTime extends Pair<Object,Long> { }
as a way of storing the result of a calculation and the time it happened.

For private/protected internal use when implementing something reasonably
self-contained, I'm very likely to prefer Pair<Object,Long>. It's simpler,
it doesn't require loading another class, and there's no danger of confusion
because it's only in code that I'm working on as a unit.

For a public API, or at a logical boundary inside my code, I prefer
ResultAndTime. It prevents a caller from getting confused between this object

But it seems stupid to me to have a file and class that have
no functional code at all. Potentially not even a constructor.

Every class has a constructor. Yours has the default no-arg constructor. And
a class's existence IS functional - it makes a specific type. Whether that
function is sufficient to justify the cost is up to you.

 

[Lew]

It is mildly criticized at:
http://forum.java.sun.com/thread.jspa?forumID=316&threadID=667720

There are consequences to subclassing. Many times they don't signify, but you
might have to cover the superclass's constructors if it has more than just a
no-arg constructor, and your custom class obtains access to protected members
of the superclass.

 

[Sideswipe]

Yes, I know all classes have atleast a default constructor. That being
said though -- I like the concept of a clearer line with this issue:
If it's a publically exposed method then do it -- The Syntax of
repeated generics is counter productive -- you could easily loose
track of what's going on -- especially when you have something like
List<Map<String,Map<String,Object>>>
filterList(List<Map<String,Map<String,Object>>>
listA,List<Map<String,Map<String,Object>>> listB)

encapsulating that Generic monster would greatly simplify the syntax
and specifically express what you're doing.

 

[Owen Jacobson]

I have come upon this several times and I am just looking for some
discussion on this:

given:

public class MyClass extends SomeClass<String,Object> {

}

which is better:

MyClass x = new MyClass();

SomeClass<String,Object> x = new SomeClass<String,Object>();

MyClass does nothing at all -- that wasn't a mistake above. It merely
declares generic types.

I like that MyClass reduces overall syntax in the code if I use it
multiple times. It also hides some detailing and allows for extra
functionality moving forward -- all while giving me the same typing
checks. But it seems stupid to me to have a file and class that have
no functional code at all. Potentially not even a constructor.

Thoughts?

This approach works if and only if everyone working on the code always
uses the stub type (MyClass) instead of the real type
(SomeClass<String,Object>). Since it's not obvious from looking at
either the definition of SomeClass<T,U> or its docs that MyClass is
the appropriate way to say "SomeClass<String,Object>" unless you
documented in SomeClass yourself, it seems almost inevitable to me
that if the project has more than just you working on it, or if you
work on it over more than a couple of months, you'll eventually use
the "wrong" type somewhere.

Since MyClass adds only vacuous semantics to the program, I wouldn't
do it this way.

CAD 0.02,
-o

 

[Lew]

> [top-posted]

Please do not top-post.

Yes, I know all classes have atleast a default constructor. That being
said though -- I like the concept of a clearer line with this issue:
If it's a publically exposed method then do it -- The Syntax of
repeated generics is counter productive -- you could easily loose
track of what's going on -- especially when you have something like
List<Map<String,Map<String,Object>>>

This would be a lot clearer if you'd drop a little white space into it, but
then, that would diminish the point you're trying to make wouldn't it?

Intellectual honesty would seem to mandate that you make the arcane idiom as
readable as possible, not as obtuse as possible, before deciding if it's
readable enough or not.

filterList(List<Map<String,Map<String,Object>>>
listA,List<Map<String,Map<String,Object>>> listB)

encapsulating that Generic monster would greatly simplify the syntax
Yes

and specifically express what you're doing.

No - it would specifically *hide* what you're doing.

This was discussed at great length recently in a thread about a proposed
"typedef" feature.

I myself am of the opinion that the generic decorations are useful, and that
the few places where a "typedef" would help are for the most part covered by
the subclassing idiom. It seems that I am in the minority in that opinion.

It is difficult for me to imagine where a List < Map <String, Map <String,
Object >>> would truly be useful, and if you did have something that rococo, I
for one would like it explicitly documented every time, specifically so that I
would *not* lose sight of how ugly and overblown the data structure is.

Can you give a use case where that structure would actually be helpful, in
lieu of refactoring it to something more reasonable?