Übungsaufgaben zu generischen Klassen und Typparametern

Kopiere den Text in ein KI-Sprachmodell Deiner Wahl und passe Kompetenzstufe, Anzahl, Bearbeitungszeit und Szenario bei Bedarf an. Wie die Aufgaben aufgebaut sind, beschreibt der Artikel Wie sind die Aufgaben aufgebaut?. Prüfe die Ergebnisse mit dem Lehrartikel: KI-Sprachmodelle machen Fehler.

Erstelle neue Übungsaufgaben zum Thema „Generische Klassen und
Typparameter“.

Bauplan: Halte Dich an Aufbau, Kompetenzstufen, Operatoren,
Anforderungsbereiche, Punkte und Zeitschätzung, die im Artikel
https://oer-informatik.de/aufgaben-aufbau beschrieben sind.

Fachliche Grundlage:
- https://oer-informatik.de/generische-klassen
- https://oer-informatik.de/sortieralgorithmen
- https://oer-informatik.de/uml-klassendiagramm
- https://oer-informatik.de/algorithmen-objektorientiert
- Stilbeispiel: https://oer-informatik.de/generische-klassen-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- Generische Klassen
- Typparameter
- Typargument
- Typsicherheit
- Vergleicher
- Comparator
- Fehleranalyse
- UML-Klassendiagramm
- Template
- Map

Kompetenzstufe: Profilkompetenz (alternativ: Basiskompetenz, Kernkompetenz, Expertise)
Anzahl: 1 Aufgabe mit Teilaufgaben
Bearbeitungszeit in Minuten ca.: <5 bis 30 min>
Szenario: eines der Szenarien aus dem Bauplan

Vorgehen:
1. Lies zuerst die verlinkten Artikel. Kannst Du keine Webseiten
   abrufen, sag mir das, statt zu raten.
2. Steht bei einer Angabe noch ein Platzhalter in <…>, frag mich
   zuerst danach. Richte Punkte und Zahl der Teilaufgaben nach der
   Bearbeitungszeit (ca. 0,9 min je Punkt).
3. Gib je Aufgabe Titel mit Kompetenzstufe, Ausgangssituation und
   Teilaufgaben mit Operator und Punktzahl aus, dazu die geschätzte
   Bearbeitungszeit.
4. Gib die Beispiellösungen mit Punkteverteilung erst aus, wenn ich
   danach frage.

List<T> ist eine generische Klasse: Ihr Code legt sich nicht auf einen Elementtyp fest. Das T ist ein Typparameter, also ein Platzhalter, den die Klasse überall dort verwendet, wo sonst ein konkreter Typ stünde – etwa beim Parameter von add oder beim Rückgabewert von get (1 Punkt). Wer die Liste benutzt, setzt einen konkreten Typ ein, das Typargument: Bei List<Aktivitaet> ist das Aktivitaet, bei List<Treffpunkt> ist es Treffpunkt (1 Punkt). Für diese Variable verhalten sich die Methoden dann so, als wären sie für den eingesetzten Typ geschrieben: add akzeptiert nur Aktivitäten, get liefert eine Aktivitaet (1 Punkt). Die Listenlogik gibt es dadurch nur einmal, und trotzdem fallen falsche Typen schon beim Übersetzen auf statt erst im laufenden Programm (1 Punkt).

• An Position 1 steht ein Benutzer-Objekt. Die Typumwandlung in Teilnahme schlägt zur Laufzeit fehl (in Java ClassCastException); das Programm bricht an dieser Stelle ab, wenn der Fehler nicht abgefangen wird (2 Punkte).

• Der Compiler kennt nur den deklarierten Typ Object. add(Object) nimmt jedes Objekt an, und ob das Objekt an Position 1 wirklich eine Teilnahme ist, hängt vom Programmablauf ab – mit dem Cast wird nur „versprochen“, dass es passt (1 Punkt).

Gegenüber ObjektListe (je 1 Punkt):

• Typsicherheit zur Übersetzungszeit: add(benutzerKim) in eine List<Teilnahme> wird schon vom Compiler abgelehnt; der Fehler kann nicht erst im laufenden Betrieb auftreten.

• Keine Typumwandlung nötig: get liefert direkt eine Teilnahme; der Code wird kürzer und lesbarer.

• (alternativ) Die Entwicklungsumgebung kann Methoden des Elementtyps vorschlagen; die Absicht („Liste von Teilnahmen“) ist im Code dokumentiert.

Gegenüber eigenen Listenklassen je Typ (je 1 Punkt):

• Wiederverwendung, keine Codeduplikation: Die Listenlogik existiert nur einmal; neue Typen brauchen keine neue Klasse.

• Wartbarkeit: Ein Fehler in der Listenlogik wird an einer Stelle behoben und gilt für alle Typen; einheitliche Methoden für alle Listen.

Je Fehler mit Begründung 1 Punkt:

• Getter auf T: getKostenEur() gibt es nur bei Aktivitaet. Ein beliebiges T (z. B. Treffpunkt) hat diese Methode nicht, die Methode lässt sich so nicht übersetzen. Der übergebene Vergleicher v wird gar nicht benutzt, obwohl genau er den Vergleich liefern soll.

• Array-Zugriff auf einer Liste: liste[i] ist für ein List<T>-Objekt nicht definiert; gelesen wird mit liste.get(i).

• Schleifengrenze: Im letzten Durchlauf ist i = liste.size() - 1, der Zugriff auf i + 1 liegt dann hinter dem letzten Element (Indexfehler zur Laufzeit). Die Schleife darf nur bis i < liste.size() - 1 laufen.

Die ersten beiden Fehler meldet schon der Compiler; der Indexfehler fällt erst beim Ausführen auf, und zwar bei jeder Liste mit mindestens einem Element, deren Nachbarn bis zum Ende richtig geordnet sind (1 Punkt).

Boolean istSortiert(List<T> liste, Vergleicher<T> v) {
    for (Integer i = 0; i < liste.size() - 1; i++) {
        if (v.vergleiche(liste.get(i), liste.get(i + 1)) > 0) {
            return false
        }
    }
    return true
}

Bewertung:

• Schleifengrenze liste.size() - 1, sodass immer zwei Nachbarn existieren (1 Punkt)

• Zugriffe mit get (1 Punkt)

• Vergleich nur über v.vergleiche(…) mit > 0; bei >= 0 würden gleichrangige Nachbarn fälschlich als unsortiert gelten (1 Punkt)

• false beim ersten falsch geordneten Paar, true erst nach der Schleife (1 Punkt)

Leere Liste und Liste mit einem Element brauchen keinen Sonderfall: Die Bedingung 0 < -1 bzw. 0 < 0 ist sofort falsch, die Methode liefert true.

class NachStadtteilUndName implements Vergleicher<Treffpunkt> {
    + Integer vergleiche(Treffpunkt a, Treffpunkt b) {
        Integer ergebnis = a.getStadtteil().compareTo(b.getStadtteil())
        if (ergebnis != 0) {
            return ergebnis
        }
        return a.getName().compareTo(b.getName())
    }
}

Bewertung: Klassenkopf mit implements Vergleicher<Treffpunkt> und passender Methode vergleiche (1 Punkt), Vergleich der Stadtteile (1 Punkt), Rückgabe dieses Ergebnisses, sobald es nicht 0 ist (1 Punkt), Namensvergleich nur bei gleichem Stadtteil (1 Punkt). Werden beide Ergebnisse einfach addiert, kann ein großer Unterschied im Namen einen kleinen Unterschied im Stadtteil überstimmen – die Rangfolge der Kriterien geht verloren.

Vergleicher<Treffpunkt> v = new NachStadtteilUndName()     // 1 Punkt
Boolean geordnet = istSortiert(treffpunkte, v)             // 1 Punkt

Der Typ der Variablen darf auch NachStadtteilUndName sein. Für T wird beim Aufruf Treffpunkt eingesetzt.

• geordnet ist false. Der erste Vergleich (Brackwede gegen Mitte) ist negativ, der zweite (beide Mitte, „Kesselbrink“ gegen „Alter Markt“) positiv – nach dem zweiten Vergleich gibt die Methode false zurück (1 Punkt).

• Geordnete Reihenfolge: 8, 15, 12, 21 (1 Punkt).

+ Warteliste(Integer maxLaenge) {
    this.maxLaenge = maxLaenge
    elemente = new List<T>()
}

+ Boolean hinzufuegen(T element) {
    if (elemente.size() >= maxLaenge) {
        return false
    }
    if (position(element) != -1) {
        return false
    }
    elemente.add(element)
    return true
}

Bewertung: Konstruktor mit Zuweisung und new List<T>() (2 Punkte), Prüfung „voll“ (1 Punkt), Prüfung „schon enthalten“ (1 Punkt, auch mit eigener Schleife), Hinzufügen und Rückgabe (1 Punkt). Wichtig: Im Code kommt kein konkreter Typ wie Teilnahme vor.

+ T naechster() {
    if (elemente.size() == 0) {
        return null
    }
    T erster = elemente.get(0)
    elemente.remove(0)
    return erster
}

Leere Liste abgefangen (1 Punkt), erstes Element in einer Variablen vom Typ T gemerkt (1 Punkt), entfernt und zurückgegeben (1 Punkt). Wer zuerst entfernt und danach get(0) liest, gibt das falsche Element zurück.

+ Integer position(T element) {
    for (Integer i = 0; i < elemente.size(); i++) {
        if (elemente.get(i) == element) {
            return i + 1
        }
    }
    return -1
}

Schleife über alle Elemente (1 Punkt), Vergleich und Rückgabe i + 1 (Platz beginnt bei 1, 1 Punkt), Rückgabe -1 nach der Schleife (1 Punkt).

Probe: Warteliste mit maxLaenge 2, hinzufuegen(lea) → true, nochmals hinzufuegen(lea) → false, hinzufuegen(malik) → true, hinzufuegen(kim) → false (voll); position(malik) → 2; naechster() → Lea, danach position(malik) → 1.

Warteliste<Teilnahme> warteliste = new Warteliste<Teilnahme>(5)

(In Java auch new Warteliste<>(5) mit Diamant-Operator.)

• Zeile 3 wird nicht übersetzt: Für interessierte ist T = Benutzer, hinzufuegen erwartet also einen Benutzer; eine Aktivitaet ist kein Benutzer (Typfehler zur Übersetzungszeit, in Java „incompatible types“) (2 Punkte).

• naechster() hat den Rückgabetyp T, hier also Benutzer. Der Wert kann direkt einer Benutzer-Variablen zugewiesen werden; der Cast ist überflüssig (1 Punkt).

• Fehler: Der Typparameter T ist nicht eingeschränkt. Der Compiler weiß deshalb nicht, ob ein beliebiges T eine Methode getAngemeldetAm() besitzt – für Benutzer gibt es sie z. B. nicht. Auf Elementen vom Typ T dürfen nur Operationen verwendet werden, die für jeden Typ gelten (2 Punkte).

• Möglichkeit 1: Den Vergleich als Parameter übergeben, z. B. T erstes(Vergleicher<T> v); im Algorithmus wird v.vergleiche(elemente.get(i), frueheste) < 0 geprüft (1 Punkt).

• Möglichkeit 2: Den Typparameter einschränken, z. B. mit einer Schnittstelle Angemeldet mit getAngemeldetAm() und class Warteliste<T extends Angemeldet>; dann sind aber nur noch Klassen erlaubt, die diese Schnittstelle implementieren (1 Punkt).

• Zusätzlicher Hinweis (ohne Punkte): Da hinzufuegen immer am Ende anhängt, steht die früheste Anmeldung ohnehin auf Platz 1. Außerdem fehlt die Behandlung der leeren Liste.

• T extends Bewertbar schränkt den Typparameter ein: Als Typargument sind nur Typen erlaubt, die die Schnittstelle Bewertbar implementieren (bzw. von ihr erben). Dafür darf die Klasse auf Elementen vom Typ T alle Methoden von Bewertbar aufrufen, hier getSterneSchnitt() (2 Punkte).

• Rangliste<Treffpunkt> r1 ist zulässig, Rangliste<Benutzer> r2 wird vom Compiler abgelehnt, weil Benutzer nicht Bewertbar ist (1 Punkt).

+ T beste() {
    if (eintraege.size() == 0) {
        return null
    }
    T bester = eintraege.get(0)
    for (Integer i = 1; i < eintraege.size(); i++) {
        if (eintraege.get(i).getSterneSchnitt() > bester.getSterneSchnitt()) {
            bester = eintraege.get(i)
        }
    }
    return bester
}

Leere Liste (1 Punkt), Startwert mit dem ersten Eintrag in einer Variablen vom Typ T (1 Punkt), Vergleich über getSterneSchnitt() mit > (bei >= würde bei Gleichstand der spätere Eintrag geliefert) (1 Punkt), Rückgabe (1 Punkt).

Bewertung:

• Warteliste mit gestricheltem Parameterkasten T an der rechten oberen Ecke, Attribute und Methoden (1 Punkt)

• TeilnahmeWarteliste mit gestricheltem Pfeil zum Template, Schlüsselwort «bind» und T -> Teilnahme (1 Punkt; alternativ eine Klasse mit dem Namen Warteliste<T -> Teilnahme>)

• Rangliste mit Parameterkasten T > Bewertbar (1 Punkt; die Schreibweise T extends Bewertbar ist als Java-Notation ebenfalls zu akzeptieren)

• Schnittstelle Bewertbar mit «interface» und getSterneSchnitt(): Real (1 Punkt)

• Realisierungen (gestrichelt, hohles Dreieck an Bewertbar) von Aktivitaet und Treffpunkt (1 Punkt)

Die «use»-Abhängigkeit von Rangliste zu Bewertbar ist optional.

• Typparameter: K (Schlüssel) und V (Wert) (1 Punkt).

• Typargumente: K = Integer, V = Warteliste<Teilnahme> – das Typargument ist selbst eine gebundene generische Klasse (1 Punkt).

• wartelisten.get(5).hinzufuegen(teilnahmeLea) (1 Punkt). get(5) liefert eine Warteliste<Teilnahme>, auf der hinzufuegen mit einer Teilnahme aufgerufen wird.