7
votes

Solution de contournement pour hachage pour un hashset lorsque l'objet interne change

La réponse à cela a donc expliqué le problème que j'ai: hachst. retirer () et iterator.remove () ne fonctionne pas

Fondamentalement, une fois que j'ajoute quelque chose au hashset, si je modifie l'un de ses champs, l'ensemble échouera tous les tests d'égalité avec un ensemble contenant un objet avec les mêmes champs, car le code de hachage qu'il a été stocké était pour quand il a eu des champs différents définis.

Donc, comme cette réponse explique ce qui se passe, quelle serait une bonne solution de contournement pour que cela ait à la fois le caractère unique d'utiliser un ensemble et être capable de modifier les champs internes des objets dans l'ensemble? Ou est-ce juste pas possible?


0 commentaires

5 Réponses :


7
votes

Supprimer l'objet que vous souhaitez modifier à partir de l'ensemble, le modifier, puis le ajouter. Autant que je sache, il n'y a pas de mise en oeuvre de type standard qui peut faire face aux champs (utilisée dans les HashCode () ou comparèteo () la mise en œuvre) étant modifiée pendant qu'elle est stockée.

Alternativement, si les champs ne sont pas utilisés utilisés pour déterminer l'identité, l'égalité ou l'emplacement (c'est-à-dire non utilisés dans hashcode () , comparète ou égale () ) alors il n'y a pas de problème.


1 commentaires

Choisir votre réponse malgré le nombre de voix, car c'est essentiellement la même chose que AIX et cela est venu quelques secondes avant :) Merci. Je pense que je pourrais réévaluer en utilisant un ensemble dans ce cas.



8
votes

Si les champs que vous modifiez ne font pas partie du test d'égalité, ils ne doivent pas non plus faire partie du calcul du code de hachage non plus. Dans ce cas, il n'y a pas de problème: vous pouvez simplement modifier ces champs.

Si les champs sont partie du test d'égalité, le moyen le plus propre est probablement de supprimer l'objet de l'ensemble, puis de le modifier et de la réinsertionner.

Si c'est ce dernier et que vous vous trouvez beaucoup de choses, vous voudrez peut-être visiter le choix de la structure de données pour le problème à la main.


0 commentaires

3
votes

Le seul moyen de contourner ce problème serait de ne pas avoir de méthode dépendant de tout champ mutable. Si des objets ont une identité et une existence indépendante des valeurs de ses champs, ceci est facile - utilisez system.identityhashashcode () . Sinon, vous pouvez baser le hashcode () sur un seul champ non mutable. S'il n'y en a pas un, alors je crains que vous n'ayez pas de chance.


0 commentaires

1
votes

Utilisez HASHMAP au lieu de hashset. Définir la clé comme quelque chose d'unique qui ne changera pas dans le temps.


0 commentaires

-1
votes

Utilisez toute autre collection (peut-être une linkedlist code>) et recherchez uniquement l'unicité uniquement au moment de l'ajout, comme dans

public class MySetList<E> extends LinkedList<E> implements Set<E> {
    private static final long serialVersionUID = 1L;

    @Override
    public boolean add(E e) {
        return new HashSet<E>(this).add(e) ? super.add(e) : false;
    }
}


0 commentaires