Weil ichs grad seh:
Ich hab ListNode nicht als interne Klasse.
Bei mir schaut das einfach so aus:
class ListNode {
public Comparable c;
public ListNode next;
}
public class SortedListImplementierung implements SortedList {
[...]public Keller add(Object c);public class Kellerimplementierung implements Keller {
private Object[] stack = new Object[256];
}
public class KellerImplementierung implements Keller{
Object[] keller;
public KellerImplementierung(){
this.keller = new Object[0];
}
public KellerImplementierung add(Object k) {
int length_old = this.keller.length;
Object[] tmp = new Object [this.keller.length+1];
if(length_old < 256){
tmp[tmp.length-1] = k;
this.keller = tmp;
}else{
System.out.println("Kann Keller nicht adden; Keller > 256");
}
return this;
}
so sieht das bisher bei mir aus und klappt auch so, jetzt frag ich mich wie das klappe soll wenn ich wie in der aufgabe public Keller add(Object k) mache, da ich ja immer auf das array keller vom Typ Object referenziere und sich dies in der KellerImplementierung befindet und nicht in Keller.java?!?Jetz mal ne ganz blöde Frage…
Aufsteigend sortiert bedeutet schon das der Head das grösste Element ist oder???
Ansonsten wär ich jetz echt verwirrt.
Also ich hab in meiner Liste halt ein „ListNode firstNode“, das enthält immer den kleinsten Wert, per next geh ich Richtung größere Werte. Womit mein head das kleinste Element trägt.
Aber ich denk ich weiß, was du meinst und ich finde der Hund is ja schonmal wieder hier begraben:
Im Skript schaut eine Liste so aus, dass vom Kopf (head) aus die Verweise jeweils auf das „vorherige“ Element zeigen. Uns wird für diesen Verweis laut Angabe der ListNode auf dem Blatt aber die Bezichnung „next“ vorgegeben. Womit uns „previous“ ein anderes „vorherig“ ist, als das aufm Skript. Und unser „next“ auf das „vorherige“ (laut Skript) zeigt, aber laut dem Namen, halt auf das „nächste“ (next)…
Ich hoff man versteht, was ich sagen will 
Aber das ist genau der Sinn von Interfaces.
Du hast deine wohldefinierte Schnittestelle und kannst damit alles machen.
Also langt es einen Keller zurückzugeben.
Ich hab’s verboten… 
Ich glaub, ich werd’s noch irgendwann ändern, aber im Moment sind bei mir ja schon keine identischen Elemente in der Liste erlaubt…
So, ich habs jetzt geschafft meine Liste soweit hinzubiegen, dass sie (fast) alle Test besteht (vielen Dank, die sind echt Gold wert!!!).
Eine Frage: Ist der Fall, dass die Liste in sich selbst eingefügt wird wirklich realistisch? Ist nämlich das einzige was bei mir noch nicht funzt.
Weiß nicht, aber es könnte ein Problem sein, wenn du deine Liste änderst und damit auch gleichzeitig die Elemente, die du gerade einfügen willst → Unendlichschleife!
Ja, genau das ist auch mein Problem.
Wie überprüfst du den Fall, ob versucht wird die Liste in sich selbst einzufügen?
Nur das erste Element zu überprüfen reich ja nicht wirklich…
Ist wesentlich einfacher:
[m]if (l == this) { … }[/m]
Danke!
Obwohl mein Programm deine Test jetzt ganz wunderbar meistert bekomm ich trotzdem nur 68%. Kann das an meinen Debug-Ausgaben liegen oder welcher Fall ist momentan noch nicht beachtet?
@immoartl: Du verbietest es wirklich, dass Elemente doppelt eingefügt werden? Vielleicht sollte ich das auch noch machen…
Und ich werd versuchen, es wieder zu erlauben… 
Ist halt dann insofern unpraktisch, weil die Element-Objekte (beim Löschen) ja auch verwendet werden, um auf Einträge Bezug zu nehmen.
Man müsste also auch da schauen, dass dann alle aus der Liste entfernt werden, und irgendwie gefällt mir dieses Konzept dann überhaupt nicht…
lol :wand:
jetz weiss ich ja wo der Hund bei mir begraben lag
THX
Warum?
Eben, meine Rede.
Also ich find du hasts doch schon treffend erklärt, und so is meiner Meinung nach auch am logischsten, warum sollte ich das gleiche Objekt zweimal in die Liste hängen wollen? Womit das was du gesagt hast find ich absolut treffend ist:
Wobei ich glaube, dass die Aufgabenstellung den Fall eh wieder überhaupt nicht berücksichtigt
Ich glaub, ich hab mich überzeugt… g
Also ich kann ein Objekt mehrmals in die Liste einfügen. d.h. sie enthällt dann beispielsweise 1, 1, 1, 3, 4, 6.
Wenn ich die 1 rauslösche, habe ich sie halt nurnoch 2x drinstehen.
So eine Liste in sich selbst kopieren klappt auch. Allerdings lege ich von meiner liste zuvor eine kopie an, die ich dann wiederum einfüge. testcase sagt 100%.
In der aufgabenstellung stand nichts davon, dass ein element nicht 2x auftauchen darf, aber das dürfte nicht viel arbeit machen, dass zu verhindern. Es zu erlauben war deutlich umständlicher, weil man bei getNext() bei zwei aufeinanderfolgenden identischen elementen ohne tricksen deutliche problem kriegt,
Ach, hab grad zum testen verboten, elemente doppelt / dreifach / … einzufügen. jetzt sagt testcase 65% obwohl ich nichts anderes verändert hab…
sehr merkwürdig.
Also mehrere gleiche Elemente sind insofern ein Problem, dass dann bei getNext(), getPrevious() und remove() keine eindeutige Zuordnung mehr möglich ist. Und durch das shuffle() kann man das eigentlich auch nicht konsisten abfangen. Solange alle gleichen Elemente aufeinander folgen, könnte man sie ja noch als Block auffassen und dann bei getNext/Previous halt das Element nach bzw. vor dem Block zurückgeben. Aber was, wenn die Liste ge-shuffelt wurde. Welches der Elemente ist dann gemeint? Der Testcase wird das wohl sowieso nicht prüfen…
Hab jetzt nochmal alles neu geschrieben und komm immerhin schon auf 85%…
So, dann schaut meine Lösung jetzt folgendermaßen aus:
// Ein Element darf nur einmal in der Liste sein,
// da es sonst bei remove(), getNext() und getPrevious()
// zu einem in der Aufgabenstellung nicht spezifizierten
// Verhalten kommen müsste.
interface
also bevor ich hier komplett falsch anfange: ist das interface so richtig?
public interface Keller
{
// create: -> Keller
// wird durch den Konstruktor der Klasse ersetzt
// add: Object X, Keller --> Keller
public Keller add(Object x, Keller k);
// pop: Keller --> Keller
public Keller pop(Keller k);
// top: Keller --> Objeckt
public Object top(Keller k);
// empty: Keller --> Boolean
public Boolean empty(Keller k);
}oder habt ihr einfach nur: “public Keller add(Object x)”, “public Keller pop()” , etc?