Is is acceptable to declare a private class as an alias?

Question

In my answer from yesterday I called the following piece of code "a hack":

final class MyMap extends HashMap<SomeSuperLongIdentifier, OtherSuperLongIdentifier> {}
// declared MyMap as an alias for readability purposes only

MyMap a = new MyMap();
a.put("key", "val");

Giving it another thought, this does not seem like a bad idea at all, but I might be missing something. Are there any potholes I missed out on? Is this an acceptable (possibly creative) way for declaring aliases in Java?

Answer 1

The drawback would be that you won't be able to directly use any methods that return a correctly typed Map, because they will never return a MyMap. Even if they could return a Map<SomeSuperLongIdentifier, OtherSuperLongIdentifier>.

For example you wouldn't be able to use the filter() methods in Maps (provided by Google Collections). They would accept a MyMap instance as input, but they would return only a Map<SomeSuperLongIdentifier, OtherSuperLongIdentifier>.

This problem can be somewhat reduced, by writing your MyMap to delegate to another Map implementation. Then you could pass the return value of such a method into the constructor and still have a MyMap (without copying, even). The default constructor could just set the delegate to a new HashMap instance, so the default usage would stay the same.

Answer 2

I would object to the name MyMap: Since you create an alias, make it document its purpose by giving it a useful name. Other than that, I like it.

Answer 3

I think it surely a convenient way to declare type synonyms. Some languages have direct support for that (in Delphi (pascal), for example, you can do that like that:

type MyMap =  HashMap<SomeSuperLongIdentifier, OtherSuperLongIdentifier>;

Since Java does not, I think you can use inheritance for that. You need to document, that this declaration is just a synonym and noone should add meethods to this class. Note also, that this consumes a little memory for VMT storage.

Answer 4

I personally would not do this, and would flag it in a review, but this is a matter of opinion.

Google Collections helps mitigate this problem, by letting you declare:

Map<SomeSuperLongIdentifier, OtherSuperLongIdentifier> a = Maps.newHashMap();

I'd look for ways to refactor code to not have to declare so many instances of this Map, perhaps.

Answer 5

As long as developers using your code have IDEs and are able to quickly jump to the class definition and read the comments for its purpose (which are in place, no?), I can see nothing wrong with it.

Answer 6

I wouldn't call it an 'alias'. It isn't. It can't be used interchangeably with the type it is supposed to be aliasing. So if that's the intention, it fails.

Answer 7

I think that inheritance is a very big gun compared to the problem at hand. At the very least I would have made this "alias class" final, with a big fat comment describing the reason for its existence.

Answer 8

Well, there are two contradictory aspects here.

1. On a modelling point of view, your declaration is right, because it emphasizes the encapsulation your class provides.
2. On a coding point of view, your declaration may be considered as wrong because you add a class only as a modelling support, with absolutely no added feature.

However, I find your approach quite right (although I never though about it before), since it provides a much appreciated (well, to me, at least) compilable model : classes from your model are perfectly reflected in your code, making your specifications executable, what is very cool.

All this brings me to say it's definitely a great idea, provided you support it with documentation.