MOin,
Y.1.1 sagt, daß man eine Testmethode zur Klasse Vorstellung in Votstellung_Test einbinden soll, die testen soll, ob Karten verkauft und storniert werden können. Wie soll das gehen ohne die drei vorgegebenen Methoden in die Klasse Vorstellung zu implementieren? <<– Das ist ja der dicke Hinweis zum Schluß dieser Aufgabe…
Ideen???
Emanuel
Ich verstehe dein Problem nicht. Du sollst die Testklasse einfach nur schreiben, da steht nirgends, dass du sie schon benutzen sollst oder gar die Tests positiv durchlaufen sollen.
Bei Film_Test z.B. hattest du doch auch erst die Testklasse und hast dann erst später die Methoden in "Film" implementiert (Stichwort "Testgetriebene Entwicklung", s. Einleitung Blatt X).
Du musst dir vorher Gedanken machen wie die Schnittstelle zu den Methoden sein soll.
Beim Kartenverkauf bietet sich an die Plätze als Parameter zu nehmen und meinetwegen nen bool als Rückgabewert, ob die Plätze reserviert wurden oder nicht.
Dazu schreibst du einen Test:
assertTrue(gibPlatz(23));
assertFalse(gibPlatz(23)); // Platz zum 2ten mal verkaufen
und danach implementierst du gibPlatz…
assertTrue(gibPlatz(23));
assertFalse(gibPlatz(23)); // Platz zum 2ten mal verkaufen
Ganz schlechte Idee [img]
http://www.fb18.de/gfx/8.gif[/img]
Eine sondierende Operation muss bei zwei aufeinanderfolgenden Aufrufen den selben Rückgabewert liefern. Eine verändernde Operation darf nichts zurückgeben. Du willst beides machen.
und meinetwegen nen bool als Rückgabewert,
und Du erzählst mir, Du kannst kein C? In P2 macht man das anders…
Die Testklasse von Vorstellung ist schon vorhanden. Die läuft unter JUnit auch wunderbar… (so weit [img]
http://www.fb18.de/gfx/28.gif[/img])
In der Aufgabe heißt es, daß man in diese Tesklasse eine Testoperation einbinden soll, die testet, ob Karten verkauft und storniert werden können. Was soll das genau heißen? Soll ich einfach irgendeine Operation schreiben, die eine noch nicht implementierte Operation von der Klasse Vorstellung testen soll, oder wie habe ich die Aufgabe zu verstehen?
Wenn ich so vorgehe wie bei Klasse Film, dann kann ich den Test doch erst erfolgreich ausführen, wenn ich die Methoden in der Klasse Vorstellung implementiert habe? Oder ist gerade Sinn der Übung, daß ich erst in der Testklasse die Methoden implementiere und dann in die eigentliche Klasse??? (<– alles klar? [img]
http://www.fb18.de/gfx/5.gif[/img]) Ich verstehe die Aufgabe wirklich nicht.
assertTrue(gibPlatz(23));
assertFalse(gibPlatz(23)); // Platz zum 2ten mal verkaufen
und danach implementierst du gibPlatz…
ah… ok. das ist ein ansatz [img]
http://www.fb18.de/gfx/22.gif[/img]
Soll ich einfach irgendeine Operation schreiben, die eine noch nicht implementierte Operation von der Klasse Vorstellung testen soll, oder wie habe ich die Aufgabe zu verstehen?
Richtig. Wie bereits erwähnt nennt sich dies "Testdriven Development". Natürlich kannst Du den Test nicht sofort ausführen. So machst Du Dir eben Gedanken, wie die zu testende Klasse sich verhalten muss.
Eine sondierende Operation muss bei zwei aufeinanderfolgenden Aufrufen den selben Rückgabewert liefern.
Wie ich dieses P2-Neusprech liebe… :)
Ich meinte "gibPlatz" nicht sondierend, sondern im Sinne von "her damit!" also reservierePlatz()…
Eine verändernde Operation darf oder sollte nichts zurückgeben? Bei Platzreservierung fände ich es generell sinnvoll wenn man den Erfolg quittiert kriegt. Dafür setX und getX aufrufen zu müssen ist doch furchtbar ineffezient?
und Du erzählst mir, Du kannst kein C? In P2 macht man das anders…
Das ich kein C kann heißt ja nicht das ich vor P2 noch nie was programmiert habe. Vielleicht kann ich nach den Semesterferien C, mal sehen wie langweilig es wird… [img]
http://www.fb18.de/gfx/25.gif[/img]
Eine sondierende Operation muss bei zwei aufeinanderfolgenden Aufrufen den selben Rückgabewert liefern.
Wirklich? Eigentlich heißt sondierend doch nur das die Methode das Objekt nicht *selber* verändern darf.
–
EP
Fred setzt dabei wohl vorraus das zwischendurch nichts anderes passiert…
Fred setzt dabei wohl vorraus das zwischendurch nichts anderes passiert…
Das würde Sinn machen. Dummerweise ist diese Vorrausetzung aber immer Falsch (wenn man wirklich streng "nichts" betrachtet), denn die Zeit schreitet notwendigerweise immer zwischen Rücksprung einer Funktion und erneutem Aufruf voran, d.h. man kann sich immer eine sondierende Funktion denken die die aktuelle Uhrzeit zurückgibt, aber bei erneutem Aufruf einen anderen Rückgabewert hat.
Wer das jetzt spitzfindig findet: Ich stimme zu, das ist spitzfindig. Andererseits ist die Vorraussetzung "Es passiert nichts zwischen den beiden Aufrufen." selber schon spitzfindig. Denn es macht keinen Sinn eine Funktion direkt zweimal hintereinander aufzurufen wenn man nach dem ersten Mal bereits das geforderte Ergebnis hat.
–
EP
Eine verändernde Operation darf oder sollte nichts zurückgeben? Bei Platzreservierung fände ich es generell sinnvoll wenn man den Erfolg quittiert kriegt.
Dafür gibt es doch Exceptions (hier z.B. PlatzSchonBelegtException [img]
http://www.fb18.de/gfx/28.gif[/img]), die den Nichterfolg "quittieren".
Fred setzt dabei wohl vorraus das zwischendurch nichts anderes passiert…
Das würde Sinn machen. Dummerweise ist diese Vorrausetzung aber immer Falsch (wenn man wirklich streng "nichts" betrachtet)
Man betrachtet aber nicht "nichts". Wenn zwischen zwei sondierenden Operationen keine
verändernde Operation aufgerufen wird, müssen die Aufrufe das selbe zurückliefern. Du darfst aber gerne irgendwelche lokalen Variablen hochzählen oder was weiss ich, das ist ja sicher etwas anderes als "nichts".
denn die Zeit schreitet notwendigerweise immer zwischen Rücksprung einer Funktion und erneutem Aufruf voran, d.h. man kann sich immer eine sondierende Funktion denken die die aktuelle Uhrzeit zurückgibt.
Komische "sondierende" Operation, die Du da vorschlägst. Nimm die Klasse Uhrzeit aus einem der letzten Aufgabenblätter. Da kannst Du 10 Jahre lang die Uhrzeit zurückgeben lassen und es wird immer das selbe rauskommen. Das meinst Du also nicht.
Eine Operation wie "gib mir die aktuelle Systemzeit" macht auf einem Objekt aber überhaupt keinen Sinn, ist also erst reicht keine sondierende Operation. Das kann man höchstens noch sinnvoll als statische Klassenoperation implementieren oder einen entsprechenden Konstruktor anbieten. Aber wie gesagt:
Exemplarvariablen verändern sich nicht einfach von selbst!es macht keinen Sinn eine Funktion direkt zweimal hintereinander aufzurufen wenn man nach dem ersten Mal bereits das geforderte Ergebnis hat.
Wirklich nicht?
do
{
meinObjekt.macheIrgendwas();
} while (meinObjekt.fehlerCode() != 0);
System.out.println("Die Schleife brach mit dem Fehlercode " + meinObjekt.fehlerCode() + " ab");
Bei Platzreservierung fände ich es generell sinnvoll wenn man den Erfolg quittiert kriegt.
Wozu gibts das Vertragsmodell?
Der Dienstleister verlangt vom Klienten, dass dieser nur freie Plätze reserviert. Dafür sichert er zu, dass ein vormals freier Platz nach der Reservierung reserviert ist.
Wenn zwischen zwei sondierenden Operationen keine verändernde Operation aufgerufen wird, müssen die Aufrufe das selbe zurückliefern.
Ja, stimmt. Aber ich wollte ja eigentlich gerade darauf hinaus das das eine Einschränkung ist die in der Praxis häufig nicht zutrifft. Man hat ja z.B. häufig die Situation das man in einem Objekt (A) eine Referenz auf ein anderes Objekt (B) hat. Jetzt hast du eine sondierende Funktion auf A deren Rückgabewert von B abhängt. Rufst du diese Funktion auf, veränderst dann B, und rufst dann erneut die Funktion auf, dann kann der Rückgabewert ein Anderer sein obwohl die Funktion sondierend ist.
Eine Operation wie "gib mir die aktuelle Systemzeit" macht auf einem Objekt aber überhaupt keinen Sinn, ist also erst reicht keine sondierende Operation. Das kann man höchstens noch sinnvoll als statische Klassenoperation implementieren oder einen entsprechenden Konstruktor anbieten.
War nicht das "Klassenobjekt" auch ein Objekt? Oder bin ich da mit der Terminologie durcheinander?
Naja, mein Beispiel war eh etwas zusammengebastelt, hatte ich ja geschrieben.
es macht keinen Sinn eine Funktion direkt zweimal hintereinander aufzurufen wenn man nach dem ersten Mal bereits das geforderte Ergebnis hat.
Wirklich nicht?
do
{
meinObjekt.macheIrgendwas();
} while (meinObjekt.fehlerCode() != 0);
Ich schrieb ja direkt.
–
EP
Wozu gibts das Vertragsmodell?
Wieso fragst Du mich das, ich finds unsinnig. [img]
http://www.fb18.de/gfx/25.gif[/img]
Also ich kann mir nicht helfen, aber ich glaube, ich denke um viel zu viele Ecken. Ich habe mich dumm und dusselig geschrieben, um das zu realisieren, was die Aufgabe verlangt… Ich habe dazu ein zweidimensionales Array (beim Aufruf des Konstruktors wird alles erst mal mit "frei" initialisiert) benutzt, die ich durchlaufe und überall und alles was "frei" ist wird gezählt. Jede Position des Array soll einen Sitzplatz repräsentieren. Damit weiß ich, daß Plätze frei sind und wieviele. Aber was ist jetzt mit dem Stornieren[img]
http://www.fb18.de/gfx/5.gif[/img][img]
http://www.fb18.de/gfx/5.gif[/img][img]
http://www.fb18.de/gfx/5.gif[/img]
ugh….
Beim stornieren setzt du den Platz wieder auf frei?
BTW, anbieten tut sich ein boolean[][], true für einen reservierten Platz, false für einen freien. So ist ohne große Initalisierung das Kino zu Anfang leer…
