Alternativ kann man das ganze auch ueber eine switch-Anweisung loesen à la:
switch(was.charAt(0))
{
case 's' : sorteAendern(neuerEintrag);
break;
case 'l' :
...
Aber mal eine Frage zu der Instanzvariablen ‘nummer’. Laut Aufgabe soll ja: [quote]nummer soll durch den Klassen-Konstruktor
gesetzt werden, um die angelegten Kaffeesorten beginnend mit 0 eindeutig zu nummerieren.[/quote]
Und im Test-Teil der Kaffee.java ruft er Kaffeesorte mit “new Kaffeesorte(0);” auf.
Allerdings haette ich jetzt spontan eher ‘nummer’ auf static gesetzt und dann in dem Konstruktor ‘nummer++’ gemacht ohne einen Int zu uebergeben.
Im anderen Fall muesste man ja theoretisch dann eine komplette Fehlerbehandlung zu dem uebergebenen Wert einbauen, die ueberprueft ob schon eine Instanz mit dem Index existiert ect.
Oder seh ich da jetzt grade was ganz falsch?
Vielleicht kann ja mal jemand kurz zeigen wie er/sie das geloest hat
Hm, aber damit koennten ja jetzt auch mehrere Instanzen mit der selben nummer kreiert werden. Ist zwar im Moment nicht weiter schlimm, weil ja mit der Variablen “nummer” sowieso nix angefangen wird, aber es ist auch nicht mehr wie in der Aufgabe genannt “eindeutig numeriert”…
Umgekehrt wuerde ein Testcase wahrscheinlich wieder Himmel und Hoelle schreien, falls ein “Kaffeesorte(int)” nicht akzeptiert wird.
Die Frage ist also, ob man die “eindeutige” Zuordnung dem Aufruf des Konstruktors ueberlaesst, oder ob man vielleicht noch nen Konstruktor à la:
public Kaffeesorte(int foo)
{
nummer++;
}erstellt…
Tja, keine Ahnung wie die das wollen oder wie ich das machen werd…
Du meinst, den Falls, dass es beispielsweise 2 Kaffeeverwaltungsinstanzen gibt, in denen die jeweiligen sorten von 0 bis Anzahl_Kaffeesorten durchnummeriert sind und willst andeuten, dass es dann Zwei Objekte Kaffeesorte mit nummer 0 gibt, von denen je eine genau einer Kaffeeverwaltung zugeordnet ist, oder hab ich dich da falsch verstanden? Falls man in diesem Fall die Nummer über den Kaffesorten-Konstruktor vergeben lässt, wird denk ich der Aufruf zum ändern einer Kaffeesorte sehr schwer, weil die Nummerierung der Kaffeesorten-objekte nicht mehr der des Kaffeesorten-arrays entspricht…Alles viel zu verrückt :#:
Jepp, so ungefaehr
Es steht ja in der Aufgabe, dass ‘nummer’ stets eindeutig sein soll, eine Uebergabe per Variable an den Konstruktor stellt die Eindeutigkeit aber nicht sicher. Somit muesste sobald es mehrere Instanzen von Kaffeeverwaltung gibt eine entsprechende Fehlerbehandlung mit eingebaut werden um die Erstellung zweier Instanzen Kaffeesorte mit gleicher nummer zu verhindern.
Es ist ja zudem noch so, dass die Instanzvariable ‘nummer’ in der hier durchgefuehrten Implementation voellig fuer die Katz ist, da die einzelnen Instanzen ja ueber die entsprechenden Referenzvariablen im Array kaffeesortenFeld identifiziert und angesprochen werden und die Instanzvariable nummer ueberhaupt nicht benutzt wird.
Aber wie du schon sagtest, eigentlich alles viel zu komplex (zumindest fuer Sonntag Abend). Vielleicht sollte man sich da vorher das eine oder andere Bier genehmigen, dann wird vielleicht alles ein bisschen klarer
Am einfachsten gehts wohl per Integer.parseInt(String)
Damit wird ein String in einen Integer-Wert umgewandelt. Theoretisch muss man vorher halt noch ueberpruefen lassen ob es wirklich auch ein ganzzahliger Wert im Int-Wertebereich ist, aber fuer die Aufgabe kann man das wohl vernachlaessigen.
man muss es nichtmal vorher überprüfen, man kann es einfach machen, sofern man es in ein try{} einpackt. im folgenden catch{} kann man dann die glaube ich NumberFormatException abfangen, falls es kein umwandelbarer String war.
also das Problem mit den static Variablen sollte sich ja jetzt geklaert haben… Macht sie static, das ist ein Fehler in der Angabe (siehe Mail). Man sieht ja mal wieder eindeutig, dass dieses Programm von den Aufgabenstellern niemand ausprobiert hat, sonst haetten sie auch gewusst, dass das Testen nach Aufgabe b nicht funktionieren kann, wenn die Klasse Kaffeeverwaltung noch nicht da ist…
Nun denn, viel spass noch beim probieren, wenn dann die Testcases da sind…
Des weiteren ergibt sich das Problem, dass sobald man den Testblock mit reinnimmt der Compiler sich an dem “return;” stoert bzw dass er den folgenden Code niemals erreicht:
Kaffee.java:25: unreachable statement
String line = "";
^
1 error
Das Ganze laesst sich allerdings umgehen indem man das “return;” durch
if(true) { return; }
ersetzt.
Und wegen dem ‘nummer’ hab ich denen jetzt mal ne Mail geschrieben und nachgefragt, wird man dann sehen wie sie sich das gedacht hatten (oder auch nicht :rolleyes: ).
cya
Nic
Ach ja, sollen denn eigentlich fuer die Aufgabe ueberhaupt noch Testcases kommen??
waren 20%. glaub ich. aber wer public vergisst bei der deklaration der klassen, wie ich, hätte eigentlich -20% verdient. dann hätte er nämlich gleich gewusst, wo ihm die 80% bzw. 120% verloren gegangen sind.
