À l'aide de deux (ou plus) objets comme une table de hachage de la clé

Vous, la clé doit mettre en œuvre le hashCode et equals. Si c'est un SortedMap, il doit également implémente l'interface Comparable

public class MyKey implements Comparable<MyKey>
{
private Integer i;
private String s;
public MyKey(Integer i,String s)
{
this.i=i;
this.s=s;
}
public Integer getI() { return i;}
public String getS() { return s;}
@Override
public int hashcode()
{
return i.hashcode()+31*s.hashcode();
}
@Override
public boolean equals(Object o)
{
if(o==this) return true;
if(o==null || !(o instanceof MyKey)) return false;
MyKey cp= MyKey.class.cast(o);
return i.equals(cp.i) && s.equals(cp.s);
}
public int compareTo(MyKey cp)
{
if(cp==this) return 0;
int i= i.compareTo(cp.i);
if(i!=0) return i;
return s.compareTo(cp.s);
}
@Override
public String toString()
{
return "("+i+";"+s+")";
}
}
public Map<MyKey,String> map= new HashMap<MyKey,String>();
map.put(new MyKey(1,"Hello"),"world");

OriginalL'auteur Pierre

La façon la plus simple que je connaisse est de faire une classe wrapper et remplacer hashmap et égaux. Par exemple:

public class KeyClass {
private String element1;
private String element2;
//boilerplate code here
@Override
public boolean equals(Object obj) {
if (obj instanceof KeyClass) {
return element1.equals(((KeyClass)obj).element1) &&
element2.equals(((KeyClass)obj).element2);
}
return false;
}
@Override
public int hashCode() {
return (element1 + element2).hashcode();
}
}

Bien sûr, je vous conseille d'utiliser un StringBuilder et tout le reste, mais de cette façon, vous avez remplacé la equals et hashcode, permettant ainsi une table de hachage et de l'égalité de vérifier sur votre touches multiples.

Aussi, je vous recommande d'en faire les objets immuables (non modifiables) pour des raisons de sécurité, mais c'est purement de préférence.

OriginalL'auteur aperkins

Voulez-vous dire que l'objet est identifié par les deux touches, ou plutôt d'une clé qui se compose de deux choses.

Si vous voulez le premier cas. C'est une objection identifié par les deux touches, dire d'une classe ou d'un objet, vous devez utiliser deux cartes.

Map<Key1, value>
Map<Key2, value>

Dans le second cas, vous avez besoin d'une carte de cartes, donc:

Map<Key1, Map<Key2, value>>

OriginalL'auteur Ethan Heilman

Il y a quelques endroits où les gens suggèrent la création d'une "Clé" de la classe contenant les autres, je suis totalement d'accord. Juste pensé que je voudrais ajouter un truc utile.

Si vous utilisez eclipse ou netbeans, ils ont une belle option--vous pouvez indiquer à Eclipse pour créer equals et hashcode des méthodes basées sur un ou plusieurs membres. Donc, il vous suffit de sélectionner les membres (ou membres) vous souhaitez récupérer par et NB crée plus de code que vous auriez besoin d'écrire pour vous.

bien sûr, quand je veux juste récupérer par un objet, je l'ai souvent juste déléguer le hashcode et equals méthodes de l'objet (avec délégation est égal pourrait être problématique car cela voudrait dire que l'un de vos "porte-Clés" les classes serait égal à l'objet qu'en est-il de la clé, mais c'est assez facilement résolu (et ne serait généralement pas l'effet de quelque chose de toute façon)

donc, hors de ma tête:

class KeyHolder {
public final String key;
public final Object storeMe;
public KeyHolder(String key, Object storeMe) {
this.key=key;
this.storeMe=storeMe;
}
public equals(Object o) {
return (o instanceof KeyHolder && ((KeyHolder)o).key.equals(key));
}
public hashcode() {
return key.hashCode();
}
}

C'est tout là est à lui, et eclipse va faire les deux derniers pour vous si vous le demandez.

Par la manière, je sais que j'ai des membres du public, un public dernier membre est exactement la même chose que d'avoir un getter--pas vraiment une idée terrible. Je commence à utiliser ce modèle sur les petites classes utilitaires comme ce beaucoup plus récemment. Si le membre n'était pas définitive, elle serait pire, car ce serait comme avoir un setter (Chose que j'essaie d'éviter ces jours-ci).

OriginalL'auteur Bill K