When defining maps in Java, users may encounter variations like:
HashMap<String, Object> map = new HashMap<String, Object>(); Map<String, Object> map = new HashMap<String, Object>();
Underlying Object
Despite these differences, both map declarations result in the same underlying object: a HashMap
Interface Difference
In the first instance, the interface type is HashMap
Coding to Interfaces
Generally, it is recommended to code to the most abstract interface (Map here) rather than a specific implementation (HashMap). This allows for flexibility in changing the underlying implementation without breaking existing code.
Example of Contract Breakage
Consider a class Foo with two HashMaps:
class Foo { private HashMap<String, Object> things; private HashMap<String, Object> moreThings; // Getters and methods using HashMaps }
A subclass SpecialFoo uses things and moreThings via methods that expect HashMaps:
class SpecialFoo extends Foo { // Methods using HashMaps }
If Foo is later updated to use TreeMaps instead of HashMaps, the type signature of things and moreThings changes. As a result, SpecialFoo breaks because it is expecting HashMaps but is now receiving TreeMaps.
Solution: Declaring Collections as Interfaces
To prevent such contract breaches, declare the collections as the most abstract interface possible:
class Foo { private Map<String, Object> things; private Map<String, Object> moreThings; // Getters and methods using Maps }
This approach ensures that SpecialFoo will not break if Foo's implementation changes.
Benefits of Coding to Interfaces
Therefore, while the two map declarations may appear different, they result in the same underlying object. Best practice dictates coding to the most abstract interface to preserve flexibility and prevent code breakage.
The above is the detailed content of What is the key difference between `HashMap map = new HashMap();` and `Map map = new HashMap();` in Java?. For more information, please follow other related articles on the PHP Chinese website!