What is the difference between the following maps I create (in another question, people answered using them seemingly interchangeably and I'm wondering if/how they are different):
HashMap<String, Object> map = new HashMap<String, Object>();
Map<String, Object> map = new HashMap<String, Object>();
Best Answer
There is no difference between the objects; you have a
HashMap<String, Object>
in both cases. There is a difference in the interface you have to the object. In the first case, the interface isHashMap<String, Object>
, whereas in the second it'sMap<String, Object>
. But the underlying object is the same.The advantage to using
Map<String, Object>
is that you can change the underlying object to be a different kind of map without breaking your contract with any code that's using it. If you declare it asHashMap<String, Object>
, you have to change your contract if you want to change the underlying implementation.Example: Let's say I write this class:
The class has a couple of internal maps of string->object which it shares (via accessor methods) with subclasses. Let's say I write it with
HashMap
s to start with because I think that's the appropriate structure to use when writing the class.Later, Mary writes code subclassing it. She has something she needs to do with both
things
andmoreThings
, so naturally she puts that in a common method, and she uses the same type I used ongetThings
/getMoreThings
when defining her method:Later, I decide that actually, it's better if I use
TreeMap
instead ofHashMap
inFoo
. I updateFoo
, changingHashMap
toTreeMap
. Now,SpecialFoo
doesn't compile anymore, because I've broken the contract:Foo
used to say it providedHashMap
s, but now it's providingTreeMaps
instead. So we have to fixSpecialFoo
now (and this kind of thing can ripple through a codebase).Unless I had a really good reason for sharing that my implementation was using a
HashMap
(and that does happen), what I should have done was declaregetThings
andgetMoreThings
as just returningMap<String, Object>
without being any more specific than that. In fact, barring a good reason to do something else, even withinFoo
I should probably declarethings
andmoreThings
asMap
, notHashMap
/TreeMap
:Note how I'm now using
Map<String, Object>
everywhere I can, only being specific when I create the actual objects.If I had done that, then Mary would have done this:
...and changing
Foo
wouldn't have madeSpecialFoo
stop compiling.Interfaces (and base classes) let us reveal only as much as is necessary, keeping our flexibility under the covers to make changes as appropriate. In general, we want to have our references be as basic as possible. If we don't need to know it's a
HashMap
, just call it aMap
.This isn't a blind rule, but in general, coding to the most general interface is going to be less brittle than coding to something more specific. If I'd remembered that, I wouldn't have created a
Foo
that set Mary up for failure withSpecialFoo
. If Mary had remembered that, then even though I messed upFoo
, she would have declared her private method withMap
instead ofHashMap
and my changingFoo
's contract wouldn't have impacted her code.Sometimes you can't do that, sometimes you have to be specific. But unless you have a reason to be, err toward the least-specific interface.