One issue with generics is how much the generic declaration repeats, particularly with collections. Consider this: bc[java]. Map<Date, List> eventBook = new HashMap<Date, List> How ugly… that repeatition gets very wearying over time. Here’s a few tips to deal with it. Tip 1: Ignore it. But it gets wearying, so let’s ignore this tip instead. … Continue reading “Generics and code clutter”
One issue with generics is how much the generic declaration repeats, particularly with collections. Consider this:
bc[java]. Map<Date, List> eventBook = new HashMap<Date, List>
How ugly… that repeatition gets very wearying over time. Here’s a few tips to deal with it.
Tip 1: Ignore it. But it gets wearying, so let’s ignore this tip instead. 🙂
Tip 2: Don’t repeat the type information. So do this instead:
bc[java]. Map<Date, List> eventBook = new HashMap()
The catch with this is that it produces compiler warnings with most IDEs, and with the Mustang Java compiler. You can fix _that_ with the annotation @SuppressWarning(“unchecked”), but that’s ugly.
Tip 3: Use generics. You can use generics to get around this problem, in a lovely case of self-reference.
bc[java].. Map<Date, List> eventBook = newMap();
…
public static Map newMap() {
return new HashMap();
}
p. Stick the newMap() method onto a utility class, bring it in via a static import, and have nice clean code again.
Author: Robert Watkins
My name is Robert Watkins. I am a software developer and have been for over 20 years now. I currently work for people, but my opinions here are in no way endorsed by them (which is cool; their opinions aren’t endorsed by me either). My main professional interests are in Java development, using Agile methods, with a historical focus on building web based applications. I’m also a Mac-fan and love my iPhone, which I’m currently learning how to code for.
I live and work in Brisbane, Australia, but I grew up in the Northern Territory, and still find Brisbane too cold (after 22 years here). I’m married, with two children and one cat. My politics are socialist in tendency, my religious affiliation is atheist (aka “none of the above”), my attitude is condescending and my moral standing is lying down.
View all posts by Robert Watkins
Software is too expensive to build cheaply.... 
Here’s something I’ve thought of but haven’t tried: Derive an empty class from the generic class. The empty class has an empty body, and acts as merely a meaningfully named alias for the generic class. Like this:
public class EventSchedule extends Map<Date, List<Event>>{}
Then use the alias everywhere.
Given that I haven’t tried it, I don’t yet know whether the idea is too ugly to live.
I have done that before for particular things. It tends to litter my code base a bit too much for me to really appreciate it. Having EventScheduleMap, EventScheduleList, EventScheduleSet repeated over and over gets tedious.
Rather than calling the newMap method newMap, if you call it map within the class New, you don’t have the unpleasantness of static imports. The same trick works for other cases, for instance Assert classes.
The solution proposed is only a workaround to the real old problem. Hey!, Foo whatever = new Foo() is also redundant.
Type inference anybody?
Type inference is exactly what this is _not_. With type inference, if I do:
bc[java]. map = new HashMap
The type of map is HashMap. With the above, it’s Map.
Type inference on variable declaration is an excellent way to toss out the good rules about programming to types, not classes, and is an amazingly bad idea.
Robert,
Type inference works well for variable declarations when you are actually creating an exact instance of the effective type, and not a subclass or an instantiated generic (as is the case here).
As much as I try to declare my variables as interfaces as much as possible (IAccount a = new Account()), I stil declare concrete types now and then and type inference would help greatly there.
—
Cedric
I agree that type inference makes declaring variables of concrete types easier. But… if you want to promote “Code to an interface”, you don’t _want_ to make declaring variables of concrete types easier.
If you work in a compile-time statically typed language (like Java, C++, and C#), the whole point of the variable declaration is to say what your type is, and to restrict the set of methods you should invoke on the instance. This is one of the most powerful aspects of a statically typed language, and one of the most useful tools available for writing readable code. Why throw it away?
I don’t know about _your_ code, Cedric, but mine isn’t dominated by variable declarations. I don’t want to lose a powerful technique to gain a little bit of faster typing in a relatively niche area.
(Now, type inference in strong dynamically typed languages – that’s a different kettle of fish all together)