Vector mit contains abfragen

[ray30002]

Moin allerseits... irgendwie komme ich hier nicht weiter, ich habe ein Vector mit Objekt der Klasse Buchstaben (enthaellt Character und int) und jetzt will ich ueber contains rausfinden, ob ein Object mit einem bestimmten Character als Wert enthalten ist... geht das?

 

[Niki]

Ja, jedoch solltest du die equals und hashCode Methoden von der Klasse Buchstaben überschreiben

 

[Leroy42]

...von der Klasse Buchstaben überschreiben

Seit wann kann eine Klasse Methoden überschreiben ?
Du meintest wohl

... der Klasse Buchstaben überschreiben

(Ich fühl' mich irgendwie so langsam müde...
... richtig müde...)

 

[ray30002]

ahh... stimmt, darauf bin ich noch garnicht gekommen.. danke, das erspart mir viel aufwand.

Gruß

ray

 

[bygones]

Ja, jedoch solltest du die equals und hashCode Methoden von der Klasse Buchstaben überschreiben

hashcode ist fuer die contains irrelevant - da wird nix gehasht...

equals reicht

 

[ray30002]

also ich nochmal, irgendwie sagen alle Quellen, welche ich im Internet finde, etwas anderes. Meine Klasse sieht folgendermasen aus:

	public BuchstabeMitAnzahl(Character c, int haeufigkeit) {
		this.c = c;
		this.haeufigkeit = haeufigkeit;
	}
	
	public Character getC() {
		return c;
	}
	public void setC(Character c) {
		this.c = c;
	}
	public int getHaeufigkeit() {
		return haeufigkeit;
	}
	public void setHaeufigkeit(int haeufigkeit) {
		this.haeufigkeit = haeufigkeit;
		
	}

Objekte dieser Klasse will ich in einen Vector schmeißen, und später überprüfen, ob in dem Vector ein Objekt dieser Klasse mit einem bestimmten Character vorhanden ist... tut mir leid, irgendwie stehe ich heute auf dem Schlauch.

Vielen Dank für die Hilfe

 

[tfa]

Ja, jedoch solltest du die equals und hashCode Methoden von der Klasse Buchstaben überschreiben

hashcode ist fuer die contains irrelevant - da wird nix gehasht...

equals reicht

Werk equals() überschreibt sollte um Gottes Willen auch hashCode() anpassen.

tfa

 

[bygones]

jaja - sollte man... dennoch ist die hashCode fuer contains irrelevant.

also...

damit es funktioniert - equals(Object o) ueberschreiben und true zurueckgeben wenn die objekte gleich sind (als zb gleicher Character und gleiche Haeufigkeit).

fuer den fleissheitspreis und eine stolzen brust alles blitzeblanko gemacht zu haben - auch noch die hashCode ueberschreiben

 

[Murray]

Bei der geposteten Klasse kann man equals und hashCode nicht gleichzeitig a) korrekt im Sinne des Contracts dieser Methoden und b) für diesen Anwendungsfall sinnvoll implementieren.

 

[ray30002]

Geht also doch nicht?

 

[tfa]

jaja - sollte man... dennoch ist die hashCode fuer contains irrelevant.

also...

damit es funktioniert - equals(Object o) ueberschreiben und true zurueckgeben wenn die objekte gleich sind (als zb gleicher Character und gleiche Haeufigkeit).

fuer den fleissheitspreis und eine stolzen brust alles blitzeblanko gemacht zu haben - auch noch die hashCode ueberschreiben

Das hat nichts mit Fleiß und Stolz zu tun. Wenn deine Klassen den Vertrag bezgl. equals und hashCode nicht einhalten, ist deine Software kaputt und du bekommst früher oder später Probleme. Punkt.

tfa

 

[Niki]

Doch, du brauchst nur auf den Character überprüfen, da ich annehme dass es pro Buchstabe nur ein Objekt gibt.

 

[Niki]

ich gebe tfa vollkommen recht, immer BEIDE Methoden implementieren!

 

[tfa]

Geht also doch nicht?

Wenn wirklich nur die Buchstaben interessieren, könnte man die Aufrufe von hashCode und equals an
die entsprechenden Methoden von c delegieren, also

public int hashCode() {
    return c.hashCode()
}

equals entsprechend.

 

[ray30002]

das probiere ich gleich mal aus. Danke du bist ein Gott

 

[Murray]

Der Contract verlangt ja, dass hashCode für ein Objekt während seiner Lebensdauer immer den gleichen Wert liefert. Daher dürfen keine Attribute zur Berechnung verwendet werden, die sich während der Lebensdauer ändern können, weil es z.B. eine set-Methode gibt. Man sollte also besser den Buchstaben als final deklarieren und nur über einen Konstruktorparameter setzen.

 

[Wildcard]

Nein, das stimmt so nicht.

Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer, provided no information used in equals comparisons on the object is modified.

 

[Leroy42]

Nein, das stimmt so nicht.

Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer, provided no information used in equals comparisons on the object is modified.

Aber genau das (großgeschriebene) hat Murray doch behauptet? ???:L

 

[SlaterB]

und das kleine Schwarze ist die Ausnahme

 

[Leroy42]

und das kleine Schwarze ist die Ausnahme

Kann das mal jemand genau übersetzen?

Für mich heisst
provided no information used in equals comparisons on the object is modified.
==
ohne Informationen des equal-Vergleichs zu nutzen, wenn
das Objekt geändert wurde

Also, für mich heisst das doch genau dasselbe wie

...ein Objekt während seiner Lebensdauer immer den gleichen Wert liefert

 

[SlaterB]

...ein Objekt während seiner Lebensdauer immer den gleichen Wert liefert,
vorausgesetzt, bei equals ist es genauso (vorausgesetzt, keine Information, die in equals verwendet wird, wird geändert)

-> wenn equals die geänderten Infos berücksichtigt, dann darf und muss hashcode() das auch und andersrum

 

[Marco13]

provided no information used in equals comparisons on the object is modified.
==
vorausgesetzt, dass keine Information, die in equals-Vergleichen des Objektes verwendet wird, wird geändert

Und das ist etwas anderes als
...ein Objekt während seiner Lebensdauer immer den gleichen Wert liefert

Ein Beispiel:

class Integer
{
    private int i;

    public void equals(Object other)
    {
        // cast, instanceof etc
       return this.i == otherInteger.i;
    }

    public int hashCode()
    {
        return i;
    }

    void set(int x)
    {
        this.i = x;
    }
}

Damit kann sich der Wert, der von hashCode geliefert wird, ändern. Allerdings hat sich dann auch "das, was das Objekt ausmacht" geändert, und wenn ein anderes Objekt vorher "equals" zum gegebenen Objekt war, ist es das nach der Änderung NICHT mehr. Damit ist der Vertrag also erfüllt.

 

[Murray]

Sorry, war gefährliches Halbwissen; dieser Zusatz ist ja wohl mit "vorausgesetzt, dass sich zwischenzeitlich keine Merkmale verändert haben, die zur Ermittlung des Resultats der equals-Methode beitragen" zu übersetzen. Insofern darf sich der Hashcode also doch durchaus mit dem internen Zustand des Objekts ändern; auch bei der equals-Methode findet sich dieser Zusatz, dort allerdings mit Hinweis darauf, dass Änderungen an Objektmerkmalen nur dann zu Änderungen des equals-Vergleichs führen dürfen, sofern diese Merkmale auch zu einem veränderten Hashcode führen.
Insofern wäre ein von einem setzbaren Member abhängiger Hashcode wohl durchaus legitim.

 

[SlaterB]

dass das bei in Maps eingebetteten Objekten zu Katastrophen führt,
wird durch so einen Satz natürlcih nicht weggewischt

 

[Leroy42]

Das wird mir jetzt zu kompliziert,
ich steige hier lieber aus und geh'
mir eine rauchen.

 

[Murray]

Zustandsabhängige Hashcodes erfüllen zwar den Contract der Klasse Object. Wenn man allerdings den Hashcode eines Objekts verwendet, um darüber das Objekt später wiederzufinden, gibt es Probleme: wenn ich ein Objekt als Key beim Einfügen in eine Hashmap verwende, ist es möglich, dass ich mit dem gleichen Objekt später bei get kein Ergebnis bekomme, wenn sich zwischenzeitlich der Zustand geändert hat. Daher können solche über die Lebensdauer des Objekts variable Hashcodes u.U. zu schwer zu findenden Fehlern führen.

 

[ray30002]

Joaaahhh... gut Oehmmm ich mach dat dann ma so irgendwie...

 

[tfa]

Joaaahhh... gut Oehmmm ich mach dat dann ma so irgendwie...

Wenn jeder Buchstabe in deinem Vector nur einmal auftreten kann, nimm lieber eine HashMap statt eines
Vector. Das könnte die Sache beschleunigen.

 

[Leroy42]

Wenn jeder Buchstabe in deinem Vector nur einmal auftreten kann, nimm lieber eine HashMap statt eines
Vector. Das könnte die Sache beschleunigen.

Richtig! HashMap ist bei solchen Aufgabenstellungen
auf jeden Fall die adäquatere Datenstruktur.

 

[ray30002]

Mach ich... danke!

 

[Murray]

Wenn es um die Häufigkeiten von Buchstaben in ASCII-Texten geht, dann ist vielleicht ein int[] mit den Buchstaben als Indizes noch einfacher:

int [] haeufigkeit = new int[256];
for ( char c : text.toCharArray()) haeufigkeit[c] += 1;

 

[Triebi]

provided no information used in equals comparisons on the object is modified.
==
vorausgesetzt, dass keine Information, die in equals-Vergleichen des Objektes verwendet wird, wird geändert
Und das ist etwas anderes als
...ein Objekt während seiner Lebensdauer immer den gleichen Wert liefert[/qoute]

Ich muss sagen, dass hier gerade mein Weltbild schwankt.
Allerdings ist dein Beispiel nicht vollständig, Ich habe es mal ausforumuliert

public class MutableInt {
    private int i;

    public MutableInt(int value) { i = value; }

    public int get() { return i; }

    public void set(int i) { this.i = i; }

    @Override public boolean equals(Object other) {
		if (other instanceof MutableInt) {
			MutableInt otherInteger = (MutableInt)other;
			return this.i == otherInteger.i;
		}
		return false;
    }

    @Override public int hashCode() { return i; }

    @Override public String toString() { return this.getClass().getName() + "[value=" + get() + ']'; }
}

und ein HashSet damit gefüttert:

import java.util.HashSet;
public class MutIntTest {
	private static MutableInt m1 = new MutableInt(1);
	private static MutableInt m2 = new MutableInt(2);
	private static MutableInt m3 = new MutableInt(1);
	private static HashSet<MutableInt> set = new HashSet<MutableInt>();
	
	public static void main(String[] args) {
		set.add(m1);
		System.out.println("-------------- Vorher ---------------");
		print();
		
		m1.set(2);
		System.out.println("-------------- Nachher ---------------");
		print();
		
		System.out.println("-------------- Inhalt vom Set ---------------");
		for (MutableInt m : set) {
			System.out.println("m.equals(m1)\t" + m.equals(m1));
			System.out.println("m.equals(m2)\t" + m.equals(m2));
			System.out.println("m.equals(m3)\t" + m.equals(m3));
			System.out.println("\t" + m + "\tHash: " + m.hashCode() + "\tim Set: " + set.contains(m));
			
		}
	}
	
	private static void print() {
		System.out.println("m1.equals(m2)\t" + m1.equals(m2));
		System.out.println("m1.equals(m3)\t" + m1.equals(m3));
		System.out.println("m2.equals(m3)\t" + m2.equals(m3));
		System.out.println("#1\t" + m1 + "\tHash: " + m1.hashCode() + "\tim Set: " + set.contains(m1));
		System.out.println("#2\t" + m2 + "\tHash: " + m2.hashCode() + "\tim Set: " + set.contains(m2));
		System.out.println("#3\t" + m3 + "\tHash: " + m3.hashCode() + "\tim Set: " + set.contains(m3));
		System.out.println();
	}
}

Teste es und sage mir, was du davon hältst.

[...]Damit ist der Vertrag also erfüllt.

Vielleicht auf dem Papier. In der Praxis halte ich es jedoch nach wie vor für gefährlich, equals/hashCode und Veränderlichkeit zu kombinieren.

 

[Marco13]

Den hashwert eines Objektes zu verändern, WÄHREND es in einem HashSet liegt, ist natürlich der Killer. Das darf man nicht machen. Wie soll die HashSet denn etwas von der Änderung mitbekommen? Das Objekt, das danach im HashSet liegt, ist (aus Sicht des HashSets) einfach nichtmehr das gleiche wie vorher!

So funktioniert es natürlich:

....
      set.add(m1);
      System.out.println("-------------- Vorher ---------------");
      print();

      set.remove(m1); // !!!
      m1.set(2);
      set.add(m1); // !!!

      System.out.println("-------------- Nachher ---------------");
      print();

EDIT: Als Nachtrag: Es ist nicht "gefährlicher" als anderes. Wenn du z.B. eine Liste von Personen nach ihrem Vornamen sortierst, und nachher den Vornamen einer Person änderst, ist die Liste danach natürlich nichtmehr unbedingt sortiert - das ist genau das gleiche.