Why is the variable declared as Map and initialized as HashMap; aren't they different types?

Question

Let's say I want to make a HashMap of grades.

 Map<String,Integer> grades = new HashMap<String,Integer>(); 
 grades.put("John", 87); // this work due to auto-boxing right?
 grades.put("Luke", Integer(85)); // non-autoboxed, is this redundant? 

Why is Map on the left and HashMap<K, V>( ); on the right? Isn't it pretty much a rule that you need type consistency whenever you create an object? Unless the static type of names is Map and the dynamic type is HashMap, which presumably is a subclass of Map. But why would you want to do this? Method calls are called from the perspective of an objects static type (e.g Maps), but if there are overridden methods in the dynamic type, those methods will be called. Is this why the types are different?

Thanks! Newbie question but this stuff can be confusing...

EDIT:

Thanks! So the general format is: Interface varName = new ImplementedClassConstructor(); ? And we often choose a superclass Interface because it allows easier substitution later (e.g. if I wanted to change HashMap to TreeMap?

Answer 1

This is called "programming to an interface" - a rather common and very useful practice.

Map<String,Integer> is an interface. It cannot be instantiated. Variables of interface types need to be assigned objects of classes that implement these interfaces.

HashMap<String,Integer> is a class that implements Map<String,Integer>, so the assignment is valid. If you decide to change the type later, and use TreeMap<String,Integer> instead of HashMap<String,Integer>, all you need to do is change the type in the new expression. The rest of your code would remain the same.

Answer 2

Look into polymorphism. Basically, a HashMap is specific type of Map, and this relationship makes the assignment possible.

Answer 3

Having a super class (or interface) on the left hand side and a specialized version on the right hand side is good practice, because it ensures that all future calls to your object only assume the super class (or interface). Hence you can easily replace your implementation (the right hand side), e.g. by a TreeMap or s.th. else.

Answer 4

In this snippet of code Map is an interface, and HashMap is a concrete class that implements that interface. Only concrete classes can be instantiated, but it's OK to assign one such instance to a variable (or attribute, etc.) declared as an interface. In fact, it's considered a good OO programming practice to do so, you should try to program to an interface whenever possible.

Answer 5

You are correct about the autoboxing.

It's good to use Map because it's more general. Let's say in the future you decide that you want to use a different type of Map, namely not a HashMap, then by keeping a Map, all you would need to do is change HashMap to a different Map implementation.