Hallo lina,
Da es keine Ordnung gibt, ist es auch nicht sinnvoll überhaupt Comparable zu implementieren. Der Vector benötigt das sowieso nicht. Comparable ist nur interessant, wenn Du irgendwie sortierst oder die Elemente in ein TreeSet o.ä. steckst und so Elemente bezüglich ihrer Größe verglichen werden müssen.
Für alles andere reicht ein Test auf Gleichheit mittels equals aus.
Das ist sprachlich immer etwas schwer zu unterscheiden, weil "vergleichen" eben "testen auf Gleichheit" oder "vergleichen bezüglich Größe" meinen kann. Comparable stellt eine Schnittstelle für letzteres zur Verfügung und die scheinst Du nicht zu brauchen.
Ich würde Comparable also nicht implementieren und equals und hashCode implementieren:
public boolean equals(Object o) {
if(o instanceof Order) {
Order order = (Order) o;
if (order.getNumber().equals(this.getNumber())) {
return true;
}
}
return false;
}
public int hashCode() {
return getNumber().hashCode();
}
equals sollte eigentlich nie irgendwie eine Ausnahme werfen. Entweder sind die Objekte gleich oder sie sind es nicht. Ungültige Eingaben für equals gibt es somit nicht. (Für compareTo gilt das nicht, zwei Objekte können durchaus unvergleichbar sein.)
hashCode soll ja eine Id des Objekts liefern und zwar so, dass gleiche Objekte auch die gleiche Id haben. Natürlich sollten möglichst wenige verschiedene Objekte, die gleiche Id haben. Das darf aber durchaus passieren. (Eine Implementierung, die z.B. immer 0 zurück gibt ist immer korrekt)
hashCode sollte man also immer so implementieren, dass man möglichst viele Eigenschaften mit einbezieht, die man in equals verwendet.
In Deinem Fall ist das nur die Nummer, also kann man einfach deren hashCode nehmen.
Grüße
Daniel