Ich soll wiedermal etwas machen, ohne dass es in der Stunde auch nur ansatzweise angekratzt wurde. Ich habe einen kleinen Text bekommen und soll dazu eine Aufruf-Schnittstelle erstellen. Ich bin mir nicht ganz sicher, wie das ganze aussehen darf, aber ich habe einfach mal was versucht. Ist das so okay?
public int reservierung (String film, String uhrzeit, int saal) throws SeatAllreadyTakenException {
String email;
int resNr;
return resNr;
}
Hier der Aufgabentext:
Angenommen, die Kinoverwaltungssoftware besitzt ein Teilsystem Kartenreservierung. Dieses Teilsystem soll eine Schnittstelle nach außen bieten, über die eine Reservierung angestoßen wird. Intern werden dann verschiedene Teilprozesse, wie die tatsächliche Blockierung der Sitzpläte im System und die Generierung der Reservierungsnummer vorgenommen. Nach außen hin muss man aber nur eine Reservier-Methode aufrufen und die gewünschten Plätze, das Datum, die konkrete Vorstellung (kapselt Film, Uhrzeit und Saal), sowie eine E-Mail-Adresse angeben. Die Methode speichert nach erfolgreichem Ablauf die Reservierung und die Kontaktdaten und gibt die Reserviernummer zurück. Versucht man, einen bereits belegten Sitz zu reservieren, erhält man eine SeatAlreadyTakenException. Geben Sie die Java-Aufruf-Schnittstelle für die Reserviermethode an
Also was wirklich Programmintern passiert ist hier irrelevant. Über Feedback würde ich mich wirklich freuen.
Eine Aufrufschnittstelle (in Java-Sprech/Englisch auch Interface) definiert die Parameter, den Rückgabetyp und (Spezialität in Java) die möglicherweise geworfene Exception. Hinzu kommt noch ein einigermaßen sprechender Name für die Methode. Rückgabetyp, benötigte Parameter und die Exception sind dem Aufgabentext direkt zu entnehmen. Folgendes Feedback dazu:
Du hast kein Interface definiert, also Fehler. Zur Definition von Interfaces in Java siehe google
Die Parameterliste entspricht nicht dem, was in der Aufgabe steht, also Fehler.
2a. Selbst bei den Parametern, die stimmen, sind deren Typen teilw. fragwürdig. Wenn von einem Datum/Uhrzeit als Parameter die Rede ist, gibt es in Java sicher bessere Typen als String. Das würde ich aber eher als unschön ansehen und nicht als harten Fehler bezeichnen.
Methodennamen in Java sollten per Konvention Verben (Tu-Wörter) sein. Auch das kein harter Fehler aber unschön.
[QUOTE=nillehammer][…]1. Du hast kein Interface definiert, also Fehler. Zur Definition von Interfaces in Java siehe google
[…][/QUOTE]
Das er kein Java-Interface definiert hat ist kein Fehler, das Wort Schnittstelle (auch im Englischen) impliziert nicht Java-Interface. Jeder popelige Typ bzw. dessen reale Inkarnation als Klasse/Objekt hat eine Schnittstelle und zwar die als öffentlich definierten Methoden.
Ein Java-Interface hingegen definiert einen eigenen abstrakten Typen der dazu verwendet wird die Schnittstelle einer Klasse teilweise oder komplett zu definieren. Das führt dann zu diesem “Contract”-Gedanken das Objekte, der Klasse welche das Interface implementiert, eine definierte Aufrufsyntax und ein gewisses “Verhalten” garantieren sollen. Diese Spaltung in einen eigenen Typen hat neben den vielen Vorteile auch Nachteile.
Im Falle des OT wäre es genauso richtig eine einfache Klasse zu schreiben mit der entsprechenden Methode die der Verwender (die Schnittstelle nach außen) dann ansprechen kann um die ganze Maschinerie “Kartenreservierung” in Gang zu setzen. Die restlichen Kritikpunkte sind berechtigt.
Stimmt, aus dem Aufgabentext ergibt sich nicht zwingend, dass ein Java-Interface zu definieren ist. Da war ich gedanklich zu sehr darin verhaftet, wie man es in Java machen würde. Was man aber rauslesen kann ist, dass es nur um die Definition der Schnittstelle geht. Es würde also reichen, die Methodensignatur vernünftig anzugeben. Die Angabe des Methodenrumpfes (der im vorliegenden Fall zudem noch völlig sinnfrei ist und auch nicht kompilieren würde) ist hier nicht nötig.
Okay, ich habe das ganze jetzt ein bischen geändert und es sieht nun so aus:
public interface IReserve {
public int reserve (String film, String uhrzeit, int saal) throws SeatAllreadyTakenException {
int platz;
string datum;
String email;
int resNr;
return resNr;
}
}
Aber ich schätze, dass das noch immer nicht ganz so ist, wie es sein soll…was sagt ihr?
a) Syntaktisch schonmal falsch. In interfaces definierst du nur die Signatur der Methode(n) - sprich: die haben keinen rumpf. [ http://openbook.galileocomputing.de/javainsel/javainsel_05_013.html#dodtp4cdf05f9-ab55-4791-9fa2-c6929cc1a19d ]
b) wie stellst du dir denn vor, wie die Werte platz, email, datum … gefüllt werden?
c) Es ist die Rede von mehreren Plätzen, bei deiner Variante könnte sich aber nur eine Person einen Sitzplatz reservieren.
Dann solltest du dir auch mal Überlegen ob ein Integer für einen Platz wirklich der richtige Datentyp wäre. In den Kinos in denen ich war, hat ein Sitzplatz richtige Koordinaten: Reihe B Platz 1. Das könnte man kurz B1 oder 1B schreiben. Dann findet sich für Datum auch ein besserer Datentyp als String ;-).
Und nochmal zur Vorstellung: konkrete Vorstellung (kapselt Film, Uhrzeit und Saal). Wenn hier von Kapseln die Rede ist, dann werden die imho auf ein Objekt heraus wollen. Da schreibst du dir einfach eine Klasse mit den 3 Attrituben.
Okay, ich glaube, dass ich es ganz am Anfang richtig gemacht habe (zumindest der Teil, in dem ich das ganze nicht als Interface definiert habe). Ich habe hier die originale Folie gefunden, auf der das einigermaßen erklärt wird. Ich bin mir nur noch nicht ganz sicher, wie ich das praktisch umsetzen kann. Hier die Folie:
Ich verstehe das so, dass das nur eine Methode ist, die alle relevanten sachen enthält, die der User aufrufen muss. Also dass die Methoden überall anders definiert werden und hier einfach nur aufgerufen…kommt das ungefähr hin? und wie setze ich das praktisch um? war mein weg zumindest okay?
Hier wäre interessant, was der Referent zu der Folie zu sagen hat. Ein Interface (von dem wir die ganze Zeit reden) hat keinen Rumpf. Alles was es definiert ist die Methodensignatur - was für den Aufrufer auch ausreichend ist. In der Folie wäre dass dann eben nur das public static double factorial(int x);. Dein erstes Beispiel ist von daher gesehen nicht richtig, weil dir Parameter fehlen und der Wert E-Mail nicht durch den Aufrufer übergeben werden kann.
Sollte die Aufgabe tatsächlich nicht als Java-Interface - sondern als Klasse gelöst werden, dann sehe dein Rumpf imho nur so aus:
{
int resNr;
...
return resNr;
}
Aber egal wie, die Parameter werden die gleichen sein. Aber dazu hatte ich ja in meinem letzten Post schon was geschrieben ;-).
Ich sollte anscheinend nur einen Javadoc comment machen. Ich poste diesen gleich
*** Edit ***
/**
*
*
* Hier können Plätze für einen Kinofilm reserviert werden. Der Kunde gibt hierfür die gewünschten Plätze,
* das Datum, die Konkrete Vorstellung, sowie seine Email-Adresse an. Wenn die Eingabe erfolgreich war,
* werden die Kontaktdaten gespeichert und dem Kunden wird seine Reservierungsnummer zurückgegeben.
* Falls der Kunde einen Sitzplatz auswählen will, der bereits belegt ist,
* wird eine entsprechende Fehlermeldung ausgegeben.
*
* @param sitze Auswahl des Sitzplatzes
* @param datum Gewünschtes Datum der Vorstellung
* @param eMail Eingabe der Emailadresse
* @param film Auswahl des Filmes
* @param uhrzeit Auswahl der gewünschten Uhrzeit für den Film
* @param saal Auswahl des Kinosaals
* @param resNr Hier entsteht die Reservierungsnummer
*
* @throws SeatAllreadyTakenException Falls ein Sitz ausgewählt wird, blockiert ist, wird eine Fehlermeldung ausgegeben
*
* @return resNr Am Ende wird die Reservierungsnummer zurückgegeben.
*
**/
Schaut nicht schlecht aus - ist aber noch nicht richtig. resNr sollte kein Parameter sein - aber als Return ist es in Ordnung (Also einfach die Zeile @param resNr … entfernen).
Bei den Punkten Film, Uhrzeit und Saal wäre ich mir nicht sicher, ob das nicht als ein Objekt (Veranstaltung) übergeben werden soll. Hier kannst du ja vllt mal bei deinen Mitstreitern nachfragen, wie die die Aussage verstanden haben. Ansonsten würde ich sagen: wenn du den Parameter resNr rausnimmst sollte es passen.
gewöhne dir einen solchen C-Stil erst gar nicht in java an …
in java hat sich folgendes schema etabliert (auch wenn es hier und da etwas gebogen wird damit am ende noch sinnvolle namen rauskommen)
interface : bekommt den eigentlichen namen z.B. List, Listener, Reservable
abstract class : bekommt ein „Abstract“ vorne dran z.B. AbstractList, AbstractListener, AbstractReservable
class : wird meist nach funktion oder implementierung, aber auch nur n schlichter name z.B. ArrayList, ActionListener, SeatReservable
sachen wie „I“ für ein Interface, „A“ für eine Abstact oder sonst irgendwelche witzigen prä- und post-fixe kommen eher aus anderen sprachen
*ja, ich weis, mir ist jetzt leider kein „dummes“ beispiel eingefallen wo man die eigentlich doch recht strickte regel etwas biegt damit der name nicht zu verwirrend wird, dürfte sich aber irgendwo in der se-api was finden lassen
/***
*** Hier können Plätze für einen Kinofilm reserviert werden. Der Kunde gibt hierfür die gewünschten Plätze,
** das Datum, die Konkrete Vorstellung, sowie seine Email-Adresse an. Wenn die Eingabe erfolgreich war,
** werden die Kontaktdaten gespeichert und dem Kunden wird seine Reservierungsnummer zurückgegeben.
** Falls der Kunde einen Sitzplatz auswählen will, der bereits belegt ist,
** wird eine entsprechende Fehlermeldung ausgegeben.
*
@param sitze Auswahl des Sitzplatzes
@param datum Gewünschtes Datum der Vorstellung
@param eMail Eingabe der Emailadresse
@param vorstellung (film, uhrzeit, saal) Auswahl der konkreten Vorstellung
@throws SeatAllreadyTakenException Falls ein Sitz ausgewählt wird der blockiert ist, wird eine Fehlermeldung ausgegeben
@return resNr Am Ende wird die Reservierungsnummer zurückgegeben.
**/
Jetzt überlege ich nur, ob ich bei der Veranstaltung mit @see nicht besser fahren würde, als mit @param. Und sollte ich dafür den Datentypen noch mit angeben (z. B. string film etc. )? Bis hierher schonmal vielen, vielen Dank für die Hilfe
