Quelle est la différence entre les objets HashMap et Map en Java?

Carte est une interface HashMap met en œuvre. La différence est que dans la deuxième implémentation, votre référence à HashMap ne permettra que l'utilisation des fonctions définies dans l'interface Map, tandis que la première permettra l'utilisation de toutes les fonctions publiques dans HashMap (qui inclut l'interface Map).

Cela aura probablement plus de sens si vous lisez Le tutoriel d'interface de Sun

J'allais juste le faire comme un commentaire sur la réponse acceptée mais c'est devenu trop funky (je déteste ne pas avoir de sauts de ligne)

Ah, donc la différence est que dans général, la carte a certaines méthodes associé avec elle. mais il y a différentes façons ou la création d'une carte, tels que en tant que HashMap, et ces différentes façons fournir des méthodes uniques qui ne sont pas toutes les cartes ont.

Exactement Exactly et vous voulez toujours utiliser l'interface la plus générale possible. Considérez ArrayList vs LinkedList. Énorme différence dans la façon dont vous les utilisez, mais si vous utilisez "Liste", vous pouvez basculer entre eux facilement.

En fait, vous pouvez remplacer le côté droit de l'initialiseur par une instruction plus dynamique. que diriez-vous de quelque chose comme ceci:

List collection;
if(keepSorted)
    collection=new LinkedList();
else
    collection=new ArrayList();

De cette façon, si vous allez remplir la collection avec un tri par insertion, vous utiliserez une liste chaînée (un tri par insertion dans une liste de tableaux est criminel.) Mais si vous n'avez pas besoin de le garder trié et que vous ajoutez simplement, vous utilisez une ArrayList (Plus efficace pour d'autres opérations).

C'est un assez gros tronçon ici parce que les collections ne sont pas le meilleur exemple, mais dans OO design, l'un des concepts les plus importants est d'utiliser la façade d'interface pour accéder à différents objets avec exactement le même code.

Modifier répondre au commentaire:

En ce qui concerne votre commentaire de carte ci-dessous, Oui, l'utilisation de l'interface "Map" vous limite uniquement à ces méthodes, sauf si vous renvoyez la collection de Map à HashMap (ce qui va COMPLÈTEMENT à l'encontre du but).

Souvent, vous allez créer un objet et le remplir en utilisant son type spécifique (HashMap), dans une sorte de méthode "create" ou "initialize", mais cette méthode retournera une "Map" qui n'a plus besoin d'être manipulée en tant que HashMap.

Si vous devez soit dit en passant, vous utilisez probablement la mauvaise interface ou votre code n'est pas assez structuré. Notez qu'il est acceptable qu'une section de votre code le traite comme un "HashMap "tandis que l'autre le traite comme une" Carte", mais cela devrait couler"vers le bas". pour que vous ne soyez jamais casting.

Notez également l'aspect semi-soigné des rôles indiqués par les interfaces. Une LinkedList fait une bonne pile ou file d'attente, une ArrayList fait une bonne pile mais une file d'attente horrible (encore une fois, une suppression provoquerait un décalage de la liste entière) donc LinkedList implémente l'interface de file d'attente, ArrayList ne le fait pas.

Map ayant les implémentations suivantes,

1. HashMap Map m = new HashMap();

2. LinkedHashMap Map m = new LinkedHashMap();

3. Arborescence De La Carte Map m = new TreeMap();

4. WeakHashMap Map m = new WeakHashMap();

Supposons que vous ayez créé une méthode (c'est juste du code spudo).

public void HashMap getMap(){
   return map;
}

Supposons que les exigences du projet changent à chaque fois comme suit,

1. La méthode devrait renvoyer le contenu de la carte-Besoin de retourner HashMap.
La méthode
2. doit renvoyer la clé map dans l'ordre d'insertion - Besoin de changer le type de retour HashMap en LinkedHashMap.
La méthode
3. doit renvoyer les clés de carte dans l'ordre trié - Besoin de changer le type de retour LinkedHashMap en TreeMap.

Si votre méthode renvoie des classes spécifiques au lieu de l'interface Map, vous devez changer le type de retour de la méthode getMap() à chaque fois.

Mais, Si vous utilisez la fonctionnalité polymorphism de java, au lieu de renvoyer la classe spécifique utilisée interface Map, Il conduit la réutilisabilité du code et moins d'impact si tout changement d'exigence.

Comme noté par TJ Crowder et Adamski, une référence est à une interface, l'autre à une implémentation spécifique de l'interface. Selon Joshua Block, vous devriez toujours essayer de coder sur des interfaces, pour vous permettre de mieux gérer les modifications apportées à l'implémentation sous - jacente-c'est-à-dire si HashMap n'était soudainement pas idéal pour votre solution et que vous deviez changer l'implémentation de la carte, vous pouvez toujours utiliser l'interface de la carte et changer le type

Dans le deuxième exemple, la "carte" de référence est de type Map, qui est une interface implémentée par HashMap (et d'autres types de Map). Cette interface est un contrat indiquant que l'objet mappe les clés aux valeurs et prend en charge diverses opérations (par exemple put, get). Il ne dit rien sur l'implémentation du Map (dans ce cas, un HashMap).

La deuxième approche est généralement préférée car vous ne voudriez généralement pas exposer l'implémentation de map spécifique à méthodes utilisant le Map ou via une définition d'API.

Map est letype statique de map, tandis que HashMap est letype dynamique de map. Cela signifie que le compilateur traitera votre objet map comme étant de type Map, même si au moment de l'exécution, il peut pointer vers n'importe quel sous-type de celui-ci.

Cette pratique de programmation contre les interfaces au lieu des implémentations a l'avantage supplémentaire de rester flexible: Vous pouvez par exemple remplacer le type dynamique de map à l'exécution, tant qu'il s'agit d'un sous-type de Map (par exemple LinkedHashMap), et modifiez le comportement de la carte à la volée.

Une bonne règle empirique est de rester aussi abstrait que possible au niveau de l'API: Si par exemple une méthode que vous programmez doit fonctionner sur des cartes, alors il suffit de déclarer un paramètre comme Map au lieu du type HashMap plus strict (car moins abstrait). De cette façon, le consommateur de votre API peut être flexible quant au type d'implémentation de carte qu'il souhaite transmettre à votre méthode.

Vous créez les mêmes cartes.

Mais vous pouvez combler la différence lorsque vous l'utiliserez. Avec le premier cas, vous pourrez utiliser des méthodes HashMap spéciales (mais je ne me souviens de personne vraiment utile), et vous pourrez le passer en tant que paramètre HashMap:

public void foo (HashMap<String, Object) { ... }

...

HashMap<String, Object> m1 = ...;
Map<String, Object> m2 = ...;

foo (m1);
foo ((HashMap<String, Object>)m2); 

En ajoutant à la réponse votée en haut et à beaucoup d'autres ci-dessus en soulignant le "plus générique, mieux", je voudrais creuser un peu plus.

Map est le contrat de structure alors que HashMap est une implémentation fournissant ses propres méthodes pour traiter différents problèmes réels: comment calculer l'index, quelle est la capacité et comment l'incrémenter, comment insérer, comment garder l'index unique, etc.

Examinons le code source:

Dans Map, nous avons la méthode de containsKey(Object key):

boolean containsKey(Object key);

JavaDoc:

Java booléen.util.Cartographie.containsValue (Valeur de l'objet)

Renvoie true si cette carte mappe une ou plusieurs clés à la valeur spécifiée. Plus formellement, renvoie true si et seulement si cette carte contient au moins un mappage vers une valeur v telle que (value==null ? v==null : value.equals(v)). Cette opération nécessitera probablement du temps linéaire dans la taille de la carte pour la plupart des implémentations de l'interface de carte.

Paramètres:valeur

Valeur dont la présence dans cette carte est à betested

Renvoie: true

Si cette carte mappe une ou plusieurs clés au{[11 spécifié]}

ValueThrows:

ClassCastException-si la valeur est d'un type inapproprié pour cette carte (facultatif)

NullPointerException-si la valeur spécifiée est null et que cette carte n'autorise pas les valeurs null (facultatif)

Il nécessite ses implémentations pour l'implémenter, mais le" comment " est à sa liberté, seulement pour assurer il retourne corriger.

Dans HashMap:

public boolean containsKey(Object key) {
    return getNode(hash(key), key) != null;
}

Il s'avère que HashMap utilise hashcode pour tester si cette carte contient la clé. Donc, il a l'avantage de l'algorithme de hachage.

Map est l'interface et Hashmap est la classe qui implémente cela.

Donc, dans cette implémentation, vous créez les mêmes objets

Map est une interface et Hashmap est une classe qui implémente Map Interface

HashMap est une implémentation de Map donc c'est tout à fait la même chose mais a la méthode" clone () " comme je le vois dans le guide de référence))

HashMap<String, Object> map1 = new HashMap<String, Object>();
Map<String, Object> map2 = new HashMap<String, Object>();  

Tout d'Abord Map est une interface qu'il a mises en œuvre différentes comme - HashMap, TreeHashMap, LinkedHashMap etc. L'interface fonctionne comme une super classe pour la classe d'implémentation. Donc, selon la règle de OOP, toute classe concrète qui implémente Map est également un Map. Cela signifie que nous pouvons affecter/mettre n'importe quelle variable de type HashMap à une variable de type Map sans aucun type de casting.

Dans ce cas, nous pouvons assigner map1 à map2 sans aucune diffusion ni perte de données -

map2 = map1