La copie d'une table de hachage en Java
J'essaie de garder une temporaire de conteneurs d'une classe qui contient membre :
HashMap<Integer,myObject> myobjectHashMap
Une classe appelée myobjectsList
Puis-je faire
myojbectsListA = new myojbectsList();
myojbectsListB = new myobjectsList();
alors: Ajoutez un peu de hashmap des éléments à Un (like2)
puis
myobjectListB = myobjectListA; //B has 2
alors: Ajouter hashmap éléments de A; (4 de plus)
revenir aux éléments stockés dans B;
myobjectListA = myobjectListb;
mais quand je fais ce B augmente avec le temps je suis ajoutant des hashmap éléments de A.
A a maintenant 6 éléments parce que B a 6.
Je veux avoir 2 encore à la fin après la dernière assingment
en C++, je voudrais utiliser la copie avec des objets, qu'est-ce que java équivalent?
Ajouté: OK j'ai oublié quelque chose expliquant cela.MyObjectsList ne contient pas la table de hachage, il est dérivé d'une classe MyBaseOjbectsList qui a la HashMap membre et MyObjectsList s'étend MyBaseOjbectsList. Cela fait-il une différence.?
- Pouvez-vous poster un SSCCE pour donner une meilleure compréhension de ce que vous avez fait jusqu'à présent?
- Vos objets doivent mettre en œuvre les Clonable interface, sinon affectations comme MyObjectB = MyObjectA tout simplement de dire la JVM que les deux variables pointent vers le même emplacement dans la mémoire. Pas deux objets distincts.
- Btw, l'écrasante idiome (pratiquement une loi) est de capitaliser les noms de classe. Il fera de votre exemples beaucoup plus lisible pour ceux d'entre nous qui utilisent ces choses comme rapide des signaux pendant l'analyse d'un exemple de code.
- pour ajouter sur @KevinWelker il contribue également à la syntaxe surligneur de mettre en évidence les noms de classe
- Merci mais essayé de faire clonable, il fit grandir quand on a grandi. Je n'en veux pas.
- s'il vous plaît partagez votre clonable code. Vous allez avoir à écrire de la mise pour vous-même. Par la création de nouvelles et de l'attribution des valeurs...etc avez-vous besoin d'une profonde contre la copie superficielle? ...etc 🙂
Vous devez vous connecter pour publier un commentaire.
Si vous voulez une copie de la table de hachage, vous devez construire une nouvelle avec.
Cela va créer une (profonde) copie de la carte.
myObjectListB.addAll(myObjectListA)
addAll
est pourHashSet
.putAll
est pourHashMap
.Vous pouvez également utiliser
Méthode pour copier tous les éléments d'une table de hachage à une autre table de hachage
Programme pour copier tous les éléments d'une table de hachage pour un autre
source : http://www.tutorialdata.com/examples/java/collection-framework/hashmap/copy-all-elements-from-one-hashmap-to-another
HashMap
etputAll
tout. C'est complètement inutile.La différence est qu'en C++, votre objet est sur la pile, alors qu'en Java, votre objet est dans le tas. Si A et B sont des Objets, en tout temps, en Java, vous n':
A et B pointent sur le même objet, donc tout ce que vous faites à vous faire à B et vice-versa.
Utiliser de nouvelles
HashMap()
si vous voulez deux objets différents.Et vous pouvez utiliser
Map.putAll(...)
pour copier des données entre deux Cartes.Il y a un petit (ÉNORME) de l'euphémisme ici. Si vous souhaitez copier un
HashMap
avec des structures imbriquées,HashMap.putAll()
copie par référence, parce qu'il ne sait pas exactement copie de votre objet. Par exemple:Donc, fondamentalement, vous aurez besoin de copier les champs-même comme ici
En Java, quand vous écrivez:
objectA
etobjectB
sont les mêmes et le point à la même référence. Le changement de l'un va changer les autres. Donc, si vous modifiez l'état deobjectA
(pas de référence)objectB
va refléter ce changement trop.Toutefois, si vous écrivez:
Puis
objectB
pointe toujours vers le premier objet que vous avez créé (originalobjectA
), tandis queobjectA
est maintenant pointe vers un nouvel Objet.Depuis que cette question est toujours sans réponse et j'ai eu un problème similaire, je vais essayer de répondre à cette question. Le problème (comme d'autres déjà mentionnés), c'est que vous venez de copier des références pour le même objet et donc de modification sur la copie va également modifier l'origine de l'objet. Donc, ce que vous avez à faire est de copier l'objet (votre valeur de la carte) elle-même. La mesure la plus simple façon de le faire est de faire de tous vos objets de mise en œuvre de la serializeable interface. Puis sérialiser et désérialiser votre carte pour obtenir une copie réelle. Vous pouvez le faire par vous-même ou utiliser apache commons SerializationUtils#clone() que vous pouvez retrouver ici: https://commons.apache.org/proper/commons-lang/javadocs/api-2.6/org/apache/commons/lang/SerializationUtils.html Mais sachez que c'est l'approche la plus simple, mais c'est cher pour sérialiser et désérialiser un lot d'objets.
Si nous voulons copier un objet en Java, il existe deux possibilités que nous avons besoin à considérer: une copie superficielle et un copie en profondeur.
La copie superficielle est l'approche à adopter lorsqu'on ne copie que les valeurs de champ. Par conséquent, la copie peut être dépend de l'objet d'origine. Dans le copie en profondeur approche, nous nous assurons que tous les objets de l'arbre sont profondément copié, de sorte que la copie n'est pas fonction d'une quelconque antérieure objet existant qui pourrait jamais changer.
Cette question est la parfaite définition pour l'application de la copie en profondeur approche.
Tout d'abord, si vous avez un simple
HashMap<Integer, List<T>>
carte alors que nous venons de créer une solution de ce genre. La création d'une nouvelle instance de laList<T>
.Celui-ci utilise
Stream.collect()
méthode pour créer le clone de la carte, mais utilise la même idée que la méthode précédente.Mais, si les instances à l'intérieur de
T
sont également mutable objets nous avons un gros problème. Dans ce cas, une réelle profondeur copie est une alternative qui permet de résoudre ce problème. Son avantage est qu'au moins chaque mutable objet dans l'objet graphique est copié récursivement. Depuis la copie n'est pas fonction d'une quelconque mutable objet qui a été créé plus tôt, il ne sera pas modifié par accident, comme nous l'avons vu avec la copie.À résoudre que cette copie en profondeur les implémentations de faire le travail.
Ce que vous assigner un objet à l'autre, tout ce que vous avez à faire est de copier les référence de l'objet, pas le contenu de celui-ci. Ce que vous devez faire est de prendre votre objet B et copier manuellement le contenu de l'objet A en elle.
Si vous le faites souvent, vous pourriez envisager de mettre en œuvre un
clone()
méthode de la classe qui permettra de créer un nouvel objet du même type, et de le copier son contenu dans le nouvel objet.Depuis l'OP a dit qu'il n'a pas accès à la classe de base à l'intérieur de laquelle existe une HashMap - j'ai peur, il y a très peu d'options disponibles.
Un (douloureusement lent et laborieux) de l'exécution d'une copie d'un objet en Java est de l'abus de la "Serializable' interface de nombreuses classes, que ce soit volontairement ou involontairement étendre - et ensuite l'utiliser pour serialise votre classe à ByteStream. Lors de la sérialisation, vous aurez une copie de l'objet en question.
Un guide pour ce qui peut être trouvé ici: https://www.avajava.com/tutorials/lessons/how-do-i-perform-a-deep-clone-using-serializable.html
Depuis Java 10 il est possible d'utiliser
pour la création d'un copie superficielle, qui est aussi immuable. (Voici son Javadoc). Pour un copie en profondeur, comme mentionné dans ce vous répondre, a besoin d'une sorte de valeur mappeur pour faire une copie de sauvegarde de valeurs. Vous n'avez pas besoin de copier clés si, puisqu'ils doivent être immuable.