Is there ever justification for the "pseudo-typedef antipattern"?

Question

I have a relatively complicated generic type (say Map<Long,Map<Integer,String>>) which I use internally in a class. (There is no external visibility; it's just an implementation detail.) I would like to hide this in a typedef, but Java has no such facility.

Yesterday I rediscovered the following idiom and was disappointed to learn that it's considered an anti-pattern .

class MyClass
{
  /* "Pseudo typedef" */
  private static class FooBarMap extends HashMap<Long,Map<Integer,String>> { };

  FooBarMap[] maps;

  public FooBarMap getMapForType(int type)
  {
    // Actual code might be more complicated than this
    return maps[type];
  }

  public String getDescription(int type, long fooId, int barId)
  {
    FooBarMap map = getMapForType(type);
    return map.get(fooId).get(barId);
  }

  /* rest of code */

}

Can there ever be any justification for this when the type is hidden and isn't forming part of a library API (which on my reading are Goetz's main objections to using it)?

Answer 1

The real problem is that this idiom creates an high coupling between your pseudo typedef and your client code. However since you are using FooBarMap privately there are no real problems of coupling (they are implementation details).

NB

A modern Java IDE should definitively helps to dealing with complicated generic types.

Answer 2

For public interfaces I don't like to see generic types, because they have no meaning. To me seeing a method with an argument of HashMap<Long,Map<Integer,String>> is much like those C methods like foo(int, int, int, void*, int) and so on. Having a real type just makes code a lot easier to read. For a public interface it would be better to create FooBarMap that wraps HashMap<Long,Map<Integer,String>> rather than 'typedef,' but for class-internal use I see no down-side at all.

Answer 3

Without this pseudo-typedef I would rather write

private Map<Long,Map<Integer,String>>[] maps;

and if I someday decide do change the implementing class from HashMap to TreeMap or Java7GreatEnhancedWonderfulMap :-) nothing will break. But with this, you are stuck with the HashMap. Well, you can make:

interface FooBarMap extends Map<Long,Map<Integer,String>> { };
class FooBarHashMap extends HashMap<Long,Map<Integer,String>> implements FooBarMap{ };

but it becomes more and more cumbersome.

Answer 4

He has a good point about this when it comes to putting it in a public interface. This idiom is emulating some form of syntactic sugar, it should not affect what you show to your clients.

But I see no good reason for not using it locally, providing that it makes you life easier and code more readable - and you known what you are doing. Brian may generalize and advise strongly against it in any situation, but that's his Goetz feeling :p

Answer 5

If you only use it in a small localised unit of code, the problems are small, true.

Thing is, so are the gains: your program probably won't even get textually smaller until you reference the pseudo-typedef 5+ times, which means the area it is visible in has to be non-trivial.

I probably wouldn't rewrite code that did this, but it seems a bad habit to get into.

Answer 6

IMO, the problem with Java anti-patterns is that they encourage black-and-white thinking.

In reality, most anti-patterns are nuanced. For example, the linked article explains how pseudo-typedefs leads to APIs whose type signatures are too restrictive, too tied to particular implementation decisions, viral, and so on. But this is all in the context of public APIs. If you keep pseudo-typedefs out of public APIs (i.e. restrict them to a class, or maybe a module), they do no real harm and they can actually make your code more readable.

My point is that you need to understand the anti-patterns and make a reasoned judgement about when and where to avoid them. Simply taking the position that "I will never do X because it is an anti-pattern" means that sometimes you will rule out acceptable, or even good solutions.