main()
Noch eine kleine Ergänzung…
…und wenn ich mir die Ausgabe von meinem eigenen Programm gscheit angeschaut hätte, wär ich schon vor einer Stunde auf 100% gewesen… 
→ evtl. auch einmal ein paar kürzere Listen probieren…
Attachment:
test.java: https://fsi.cs.fau.de/unb-attachments/post_30252/test.java
Dürfen bei dir gleiche Elemente doppelt in der Liste vorkommen, also 2x 3 etc.?
Wenn 2x z.B. die selbe Zahl drin ist (–> [m]a.compareTo(b) == 0[/m]), ist das Ganze kein Problem.
Falls zweimal das selbe Objekt in die Liste soll ([m]a==b[/m]), ignoriert mein Programm das zweite. Weiß nicht, ob ich das so machen soll, aber es ist in der Test-Funktion vor allem deswegen drin, weil u.U. ziemlich ekelhafte Fehler entstehen könnten, wenn man eben nicht drauf aufpasst.
Die 9.1 kommt mir etwas komisch vor… Ich hab gedacht, die Klasse KellerImplementierung so zu machen, dass sie ein Array in sich trägt und bei Bedarf diese primitiven Operationen an diesem Array ausführt… Wenn man aber genauer liest, kommt man dadrauf, dass die Funktionen gar nicht das Array vom eigenen Objekt bearbeiten sollen, sondern eine Referenz auf Keller übernehmen und dessen Array bearbeiten… kommt es euch nicht komisch vor? ist doch total unlogisch! wie habt ihr das gelöst?
Lotec nenene.
das steht doch drin, dass man eine objektorientierte Version des Kellers implementieren soll.
Alles andere wäre ja wohl auch ziemlicher Quatsch.
ja gut, würde ich auch so sehen, die Funktion add z.B übernimmt aber ein Objekt vom Typ Keller als Parameter… wozu soll das denn gut sein??:wand:
Tut sie nicht, wenn du das Ganze auf objektorientiert änderst. Dann weißt du ja ohnehin, auf welchem Objekt du gerade arbeitest, und zurückgeben musst du auch keines, weil du ja den Zustand des Objekts ändern kannst.
Aus [m]add(Object,Keller) → Keller[/m] wird also [m]Keller.add(Object)[/m], wenn man’s mal ganz unschön formuliert.
…oder sollte das der Grund dafür sein, dass alle 0% haben? :moody:
ich gehe stark davon aus, dass du recht hast, einfach aus dem Grund, dass du mit der Referenz auf Keller sowieso nicht auf das array zugreifen kannst… in der Aufgabenstellung steht aber add: Object x Keller, und das verwirrt mich ziemlich…
Das liegt halt daran, dass du bei einem rein prozeduralen Ansatz gar keine andere Wahl hast, als dein Array als Parameter mitzuschleifen…
Übrigens:
Es macht für die 0% beim Testcase offenbar keinen Unterschied, ob
add & Co. den Keller zurückgeben oder nicht…
Du hast 100% bei der SortedList? Hast du das mit [m]implements SortedList[/m] gemacht, oder ohne Interface? Hast du die interne ListNode Klasse private gemacht? Bekommen nämlich nur 5% und d.h. ja, dass der Testcase die Methoden nicht aufrufen kann…
Ja
Ja, [m]private static[/m], aber ob das einen Unterschied macht?
Weil es in der Aufgabenstellung in dieser (komischen) Schreibweise (wie in der Vorleseung) beschrieben ist.
Damals gab’s eben noch kein UML.
UML ist wohl kaum ein Ersatz für die axiomatische Beschreibung einer Datenstruktur. Insbesondere kannst du mit UML nicht “rechnen”, somit werden Verifikations-“beweise” so schwammig das es sich nicht wirklich lohnt.
Das die objektorientierte Sichtweise mit der gegebenen Beschreibung in Konflikt steht, hängt vor allem damit zusammen das die relevanten (aus der Sicht eines OOPlers) Abstraktionsniveaus (Kapselung, Polymorphie, you name it) nur durch Klassenstrukturen entstehen dürfen. Ich sag jetzt mal lieber nichts zum funktionalen Standpunkt. :>
Rekursive Beschreibungen sind sowieso Trumpf!
w00t w00t, λ-bitching. 
hab grade Keller hochgeladen- 0%
Hat irgendwer schon mehr als 0% ?
Weil prinzipiell könnte es ja einfach sein, dass die ein anderes Interface verwenden und sich das Ganze dann halt nicht mehr compilieren lässt → 0%…
Oder der Testcase geht einfach net… 
So, ich hab den Keller jetzt mit einem Wahnsinns-Aufwand auf [m]public Keller add(Object item, Keller stack)[/m] umgeschrieben – und gebracht hat’s mir immerhin 0%…
Damit hätte ich jetzt glaub ich alle Möglichkeiten durch → der Testcase muss kaputt sein…
Attachment:
KellerImpAdd.java: https://fsi.cs.fau.de/unb-attachments/post_30282/KellerImpAdd.java
Testcasegesabber
Warum rennt ihr denn immer so dem Testcase hinterher.
Ich gebe auf den nichts mehr.
Wenn mein Programm das macht, was in der Aufgabenstellung gefordert ist - dann bin ich glücklich!
thx immoartl
Vielen Dank immoartl für dein Testfile für die 9.2. Hat mir gute Dienste geleistet (jetzt 100%), auch wenn ich große Teile nochmal umschreiben musste, um eine Liste in sich selbst einfügen zu können.
Muss trotzdem noch weng tricksen in diesem fall, d.h. eine kopie von der liste erzeugen und die dann einfügen.
wie hast du das ganze gelöst?
gruß und ein schönes wochenende
thomas
Muss mich da thomas anschließen: Thx immoartl!
Wollt mir grad selber eine main mit paar Tests schreiben, da hab ich deine hier im Thread gesehen. Taugt 100%, is ja alles drin, praktisch jede denkbare Spielerei, Listen mit gerader und ungerader Anzahl an Elementen shufflen, sogar das mit gleichem Element einfügen.
Sag ich mal danke, getestet und für gut befunden 
(Zum Testcase: Ja, hab bei List auch 100% und beim Keller 0%, also kein Stress)
edit → hat sich erledigt