Besprechung des Projekts Keep or Throw mit Typparameter und Übungen zu generischen Klassen & Beziehungen zwischen Objekten

Zu Beginn der Stunde hat Tim seine Keep Or Throw Basisversion vorgestellt. Er hat den Typparameter eingebaut jedoch hat er einen häufig vorkommenden Fehler gemacht. Beim Erzeugen eines Stapels in der Spiel Klasse hat er den Typparameter nicht mitgegeben, deswegen musste er trotz des Typparameters weiterhin Typecasts verwenden um Fehlermeldungen des Compilers zu vermeiden. Der Compiler hat einen Fehler angezeigt, da T nicht festgelegt wurde und dann automatisch auf Objekt festgelegt wurde, dadurch konnte Tim nicht Karten die er vom Stapel nehmen wollte als Karte abspeichern, da Karte eine Unterklasse von Objekt ist.

Danach haben wir die Aufgabe 2 der Übungen zu Keep Or Throw angefangen. Wir sollten ein Objektdiagramm anlegen zu dem konkreten Beispiel der Aufgabe. Danach sollten wir dazu noch die passenden Klassendiagramme hinzufügen. Das „optional“ sollten wir aus der Aufgabe drei streichen und mussten das Grundgerüst sowie die Tests erzeugen. In Aufgabe 2.4 und 2.5 sollten wir dann die Klassen vollständig implementieren und uns dabei überlegen ob es sinnvoll ist generische oder innere Klassen zu benutzen. Es gab zwei Varianten wie man den Typparameter einbauen konnte, damit die Paare in der Aufgabe aus zwei beliebigen Lebewesen oder Sachen bestehen können. Die erste Möglichkeit wäre, dass man beim erzeugen eines Paars den Typparameter als Objekt festlegt. Die zweite Variante wäre, dass man zwei Typparameter benutzt, die mit einem Komma getrennt werden <T, J>. Bei der zweiten Methode bekommt man jedoch Schwierigkeiten bei der getPartner() Methode.

Objektdiagramme zu Aufgabe 2.1
Klassendiagramme zu Aufgabe 2.2
  • HA:
  • -Objekt-/Klassendiagramme fertig stellen oder berichtigen
  • Implementierung und Tests fertig machen

Schreibe einen Kommentar