Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
Unimodale Suche
Hallo,
ich finde die Aufgabenstellung der 9.2 “Unimodale Suche” vollkommen unverständlich und unvollständig und würde daher gerne wissen, was man da eigentlich machen muss.
Welche Argumente bekommen die zu implementierenden Methoden in welcher Reihenfolge? Welche Bestandteile außer den Methoden (z.B. Comparators, Comparables) muss man noch implementieren?
Wie müssen die Methoden überhaupt heißen? Aus dem PublicTest gehen leider nicht alle Sachen eindeutig hervor.
Danke im Voraus 
1 „Gefällt mir“
Ihr müsst nur die beiden geforderten Methoden implementieren. Wie sie heißen und welche Parameter sie haben, lässt sich an sich schon aus dem PubTest ableiten. Du musst nur daran denken, dass die Methoden generisch sein müssen; das heißt sie sollen mit UnimodalenListen arbeiten, die beliebige Objekte enthalten können, welche sich aber auf jeden Fall vergleichen lassen.
1 „Gefällt mir“
Das heißt also, man kann einfach java.lang.Comparable bzw java.util.Comparator vor der Klasse importieren um mit den Interfaces arbeiten zu können? Ansonsten müsste man die Methoden der Interfaces ja in der eigenen Klasse überschreiben… Außerdem frage ich mich, wie man die Methode hole(int index) aus dem Interface UnimodaleListe in der zu implementierenden Klasse UnimodaleSuche überschreiben soll, wenn man doch von UnimodaleListe nichts kennt…
Ja, du musst die entsprechenden Interfaces importieren, damit dein Compiler sie kennt.
Die Methode hole(int Index) musst du nicht überschreiben, das Interface dient lediglich dazu, euch zu zeigen, was die Listen, welche euren Methoden übergeben werden, auf jeden Fall können (nämlich zu einem gegebenen Index das entsprechende Listenelement zurückgeben).
Wie muss der Methodenkopf denn aussehen?
Ich bin aktuell dabei
public int suche(Comparable<T> c, int a, int b) {
return 0;
}
public int suche( Comparator<T> x, int a, int b, Comparator<T> c) {
return 0;
}und das stimmt offensichtlich nicht, der PublicTest findet die Methoden nämlich nicht. Man kann aber keine Klasse verwenden, die im PubTest vorkommt, weil die alle private sind.
Das erste Parameter ist bei beiden eine Unimodale Liste… Rückgabe ist ein Object aus der Liste…
classCastException
Hallo, ich hab ein Problem. Einer der Parameter der Methoden ist ja eine UnimodaleListe.
Wenn ich aber im Methodenkopf "public static … suche(UnimodaleListe , …){} stehen habe, meckert der publicTest, dass folgende classCastException auftritt:
java.lang.ClassCastException: UnimodaleSuchePublicTest$LongDingComparator cannot be cast to UnimodaleListe
Wie behebe ich das denn? Die Pub-Test-Klassen sind ja alle private, die kann und soll ich ja sowieso nicht verwenden und ich kein Objekt aus UnimodaleSuchePublicTest$LongDingComparator übergeben.
(Tritt diese Exception in einer Zeile des PublicTests oder in einer Zeile deines Codes auf?
Wenn sie in deinem Code auftritt, hast du vermutlich eine fehlerhafte Zuweisung (siehe Beispiele auf den Tafelübungsfolien) geschrieben.
Generell ist bei Exceptions die Angabe der Zeile, in der sie geworfen wurde, ein großer Hinweis auf den Fehler.)
Das, was Destranix sagt. Ich habe das “Comparator” überlesen.
Die Fehlermeldung ist doch relativ eindeutig… Du hast in deiner Methode als Eingfabeparameter irgendwo etwas vom typ Unimodale Liste stehen, wo eigentlich ein Comparator stehen sollte…
Noch eine Frage:
Die compareTo Methode, die ich mit elem1.compareTo(elem2) mit elem vom Typ T aufrufe muss ja einen int-Wert zurückgeben, nur kann ich ja zwei Parameter vom Typ T nicht direkt voneinander abziehen und casten funktioniert auch nicht.
Außerdem weiß ich nicht ob ich die compareTo Methode wirklich so aufrufen kann, denn der Compiler meckert dann immer, dass er die Methode nicht findet, obwohl sie implementiert ist.
In den Tafelübungsfolien klappt das so schön, aber hier irgendwie nicht. Wär schön, wenn mir jemand helfen könnte.
Die compareTo-Methode musst du nicht selber implementieren, jede Klasse, die Comparable implementiert, muss eine Implementierung dieser Methode bereitstellen (oder abstrakt sein).
Du musst dafür sorgen, dass deine T’s diese Einschränkung besitzen, also dass deine Methode nur T’s akzeptiert, die Comparable implementieren. Sonst kannst du natürlich nicht davon ausgehen, dass deine T’s diese Methode zur Verfügung stellen.
Dem muss ich mich absolut anschließen. Ich habe noch nie eine solch schlechte und unvollständige Aufgabestellung gesehen. Nach 2 Stunden habe ich sie aufgegeben, das macht einfach keinen Sinn.
Ich möchte darauf hinweisen, dass die öffentlichen Testfälle bei der Bearbeitung der Aufgabe trotz mangelhafter Aufgabenstellung helfen können…