Übungsaufgaben zu Polymorphie und später Bindung

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 „Polymorphie und später Bindung“.

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/uml-klassendiagramm-polymorphie
- https://oer-informatik.de/uml-klassendiagramm-vererbung
- https://oer-informatik.de/uml-klassendiagramm-interface-abstraktion
- https://oer-informatik.de/entwurfsmuster
- Stilbeispiel: https://oer-informatik.de/uml-klassendiagramm-polymorphie-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- Polymorphie
- Späte Bindung
- UML-Klassendiagramm
- Abstrakte Klasse
- Überschreiben
- Überladen
- Zustandsmuster
- Vererbung

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.

• Der Fall "APP" fehlt in adresseGueltig(). Der Aufruf landet im default-Zweig und bricht mit einer IllegalStateException („Unbekannter Kanal: APP“) ab (1 Punkt).

• Für den Compiler ist kanal nur irgendein String. Ob jeder mögliche Wert in jeder Methode behandelt wird, kann er nicht prüfen; der Fehler zeigt sich erst zur Laufzeit (1 Punkt).

• Dieselbe Fallunterscheidung steht in mehreren Methoden. Wer einen neuen Kanal einführt, muss alle diese Stellen finden und ergänzen – eine vergessene Stelle fällt erst im Betrieb auf (1 Punkt).

Je Mangel 1 Punkt für das Erkennen, 1 Punkt für die korrekte Darstellung im Diagramm:

• Kanal ist eine gewöhnliche Klasse mit konkreten Methoden aufbereiten und adresseGueltig. Eine allgemeine Aufbereitung „für irgendeinen Kanal“ gibt es aber nicht: Kanal wird abstrakt, die beiden Methoden ebenfalls (kursiv bzw. {abstract}). Dann lassen sich keine Kanal-Objekte ohne Kanalart mehr erzeugen, und jede Unterklasse muss beide Methoden implementieren.

• MailKanal hat aufbereiten(text: String, anrede: String) mit einem zusätzlichen Parameter. Das ist keine Überschreibung, sondern eine Überladung: Ein Aufruf k.aufbereiten(text) über eine Kanal-Referenz würde die Methode aus Kanal ausführen. Die Signatur muss gleich sein: aufbereiten(text: String): String.

• SmsKanal überschreibt keine der beiden Methoden. Ist Kanal abstrakt, übersetzt der Compiler die Klasse so nicht; SmsKanal braucht eigene Implementierungen von aufbereiten und adresseGueltig.

• Kundenkonto kennt die drei Unterklassen einzeln. Dann braucht benachrichtigen wieder drei getrennte Schleifen, und für jeden neuen Kanal muss Kundenkonto geändert werden. Richtig ist eine gerichtete Assoziation zur Oberklasse Kanal, Multiplizität 1..* (der Konstruktor verlangt einen ersten Kanal; 0..* wird ebenfalls akzeptiert).

AppKanal: Dein Rahmen ist lackiert und geht mor...
MailKanal: Hallo! Dein Rahmen ist lackiert und geht morgen in die Montage. Dein CSB-Rad-Team
2 Nachricht(en) versendet

Bewertung (4 Punkte): 1 Punkt App-Zeile (der Text hat 56 Zeichen und wird auf 37 Zeichen plus „…“ gekürzt), 1 Punkt Mail-Zeile, 1 Punkt: keine SMS-Zeile, weil 0521 9988770 nicht mit + beginnt und adresseGueltig() deshalb false liefert, 1 Punkt Anzahl 2.

• k hat den Referenztyp Kanal. Der Compiler prüft nur, dass Kanal die Methode aufbereiten(String) deklariert – mehr weiß er über k nicht (1 Punkt).

• In der Liste stehen Objekte verschiedener Unterklassen, die aufbereiten jeweils mit gleicher Signatur überschreiben. Welche Kanäle eine Kundin hinterlegt hat und in welcher Reihenfolge, steht erst fest, wenn das Programm läuft – im Shop kommen sie aus dem Kundenkonto in der Datenbank (1 Punkt).

• Bei jedem Schleifendurchlauf wählt die Laufzeitumgebung anhand der Klasse des Objekts, auf das k gerade verweist, die passende Implementierung aus (späte bzw. dynamische Bindung). Dieses Zusammenspiel aus gemeinsamer Oberklasse, Überschreiben und später Bindung heißt Polymorphie (1 Punkt).

• Variante A ist richtig: Sie setzt „EILT: “ vor den Text und überlässt das Kürzen auf 160 Zeichen der geerbten Implementierung von SmsKanal. Bei 158 Zeichen entsteht ein 164 Zeichen langer Text, der auf 157 Zeichen plus „…“ gekürzt wird – das Ergebnis hat genau 160 Zeichen (2 Punkte).

• Variante B kürzt zuerst und setzt das Präfix danach davor. Kurze Texte sehen richtig aus, bei 158 Zeichen entstehen aber 164 Zeichen – die SMS-Grenze wird überschritten (1 Punkt).

• Variante C ruft ohne super sich selbst auf: Der Aufruf geht über this an die überschriebene Methode von EilSms, die wieder sich selbst aufruft. Die Rekursion endet nie, das Programm bricht mit einem StackOverflowError ab (1 Punkt).

public class EilSms extends SmsKanal {

    public EilSms(String mobilnummer) {
        super(mobilnummer);                       // Konstruktor von SmsKanal
    }

    @Override
    public String aufbereiten(String text) {
        return super.aufbereiten("EILT: " + text); // Kürzen erledigt SmsKanal
    }
}

Bewertung (3 Punkte): 1 Punkt extends SmsKanal, 1 Punkt Konstruktor mit Aufruf super(mobilnummer), 1 Punkt überschreibende Methode mit gleicher Signatur und Aufruf der Oberklassenmethode. adresseGueltig() wird von SmsKanal geerbt und muss nicht erneut implementiert werden. Weil EilSms (über SmsKanal) ein Kanal ist, nimmt kanalHinzufuegen(k: Kanal) das Objekt ohne Änderung an.

Je Zeile 1 Punkt (Entscheidung und Begründung). Hätte k1 auf einen MailKanal verwiesen, wäre die dritte Zeile ebenfalls übersetzt worden, aber zur Laufzeit mit einer ClassCastException abgebrochen.

• Vorteil des Vorschlags: Tippfehler wie "Sms" sind ausgeschlossen, weil nur die drei Konstanten erlaubt sind; die Änderung ist klein (1 Punkt).

• Nachteil: Die Fallunterscheidungen bleiben in jeder Methode stehen. Ein neuer Kanal (z. B. ein Messenger) erfordert weiterhin Änderungen an allen switch-Anweisungen der getesteten Klasse; kanalspezifische Daten und Regeln bleiben in einer Klasse vermischt (1 Punkt).

• Polymorphe Lösung: Ein neuer Kanal ist eine neue Unterklasse, Kundenkonto und vorhandene Kanäle bleiben unverändert (Offen-geschlossen-Prinzip); vergisst die neue Klasse eine Methode, meldet das der Compiler, weil die Methoden in Kanal abstrakt sind. Der Mehraufwand an Klassen lohnt sich, sobald Kanäle häufiger dazukommen oder sich im Verhalten stark unterscheiden (1 Punkt).

Bewertung (8 Punkte):

• 1 Punkt: Anzeigezustand als abstrakt gekennzeichnet.

• 1 Punkt: beide Methoden in Anzeigezustand als abstrakt.

• 3 Punkte: je Zustandsklasse beide Methoden als überschreibende (konkrete) Methoden mit vollständiger Signatur.

• 2 Punkte: drei Vererbungsbeziehungen zu Anzeigezustand (1 Punkt bei einem Fehler).

• 1 Punkt: gerichtete Assoziation von Raumanzeige zu Anzeigezustand mit Multiplizität 1 beim Anzeigezustand, passend zum Attribut zustand. In der Lösung steht zustand als Rollenname am Assoziationsende, das Attribut entfällt deshalb in der Klasse. Bleibt das vorgegebene Attribut stehen und kommt die Assoziation hinzu, gibt es ebenfalls den Punkt.

Abhängigkeiten der Zustandsklassen zu Raumanzeige (über den Parameter r) dürfen zusätzlich als gestrichelte Pfeile eingezeichnet werden, sind aber nicht gefordert.

Ablauf (3 Punkte):

1. zustand verweist auf ein Umbaupause-Objekt. zustand.minuteVergangen(this) führt deshalb Umbaupause.minuteVergangen(r) aus: Die Pausenminuten sinken auf 0, die Methode setzt über r.setZustand(new Frei()) einen neuen Zustand (1 Punkt).

2. Die zweite Zeile zustand.anzeigetext(this) liest das Attribut erneut. Es verweist jetzt auf das neue Frei-Objekt, also läuft Frei.anzeigetext(r) (1 Punkt).

3. Rückgabe: „A 204: frei“ (1 Punkt).

Einwand widerlegt (2 Punkte):

• Das Attribut zustand hat den Typ der abstrakten Klasse Anzeigezustand. Alle Zustandsklassen erben davon und überschreiben beide Methoden mit gleicher Signatur. Raumanzeige muss deshalb nur wissen, dass es einen Anzeigezustand gibt, nicht welchen (1 Punkt).

• Welche Implementierung ausgeführt wird, entscheidet die Laufzeitumgebung bei jedem Aufruf anhand des Objekts, auf das zustand gerade verweist (späte Bindung) – im Beispiel sogar innerhalb desselben aktualisieren()-Aufrufs zweimal verschieden. Die „Abfrage“ steckt also in der Auswahl der Klasse; eine Fallunterscheidung in Raumanzeige wäre doppelt und müsste bei jedem neuen Zustand geändert werden (1 Punkt).

öffentlich minuteVergangen(r: Raumanzeige)
    r.setRestminuten(r.getRestminuten() - 1)
    wenn r.getRestminuten() <= 0 dann
        r.setRestminuten(10)
        r.setZustand(neu Umbaupause())
    ende wenn
ende minuteVergangen

Bewertung (5 Punkte):

• 1 Punkt: Signatur passend zur abstrakten Methode (überschreibend).

• 1 Punkt: Restminuten über die übergebene Raumanzeige um eins verringern.

• 1 Punkt: Bedingung „abgelaufen“ (<= 0 oder == 0).

• 1 Punkt: Pausendauer 10 Minuten setzen.

• 1 Punkt: Zustandswechsel mit einem neuen Umbaupause-Objekt über r.setZustand(...).

• Es handelt sich um Überladen (overloading): gleicher Methodenname, aber andere Parameterliste (zusätzlicher Parameter sprache) (1 Punkt).

• Beim Überladen entscheidet der Compiler anhand von Anzahl und Typen der Argumente, welche Methode aufgerufen wird (statische bzw. frühe Bindung) (1 Punkt).

• Überschreiben (overriding) liegt vor, wenn eine Unterklasse eine Methode der Oberklasse mit gleicher Signatur neu implementiert, wie anzeigetext(r: Raumanzeige) in Frei, SessionLaeuft und Umbaupause (1 Punkt).

• Beim Überschreiben wird erst zur Laufzeit anhand der tatsächlichen Klasse des Objekts entschieden (späte bzw. dynamische Bindung). Nur das Überschreiben ist die Grundlage der Polymorphie im Zustand-Entwurfsmuster (1 Punkt).

öffentlich alleAktualisieren(): List<String>
    texte: List<String> = neu List<String>()
    für jede anzeige in anzeigen
        texte.hinzufügen(anzeige.aktualisieren())
    ende für
    rückgabe texte
ende alleAktualisieren

Bewertung (4 Punkte): 1 Punkt neue Ergebnisliste, 1 Punkt Schleife über alle Raumanzeigen, 1 Punkt Aufruf von aktualisieren() je Raumanzeige und Hinzufügen des Rückgabewerts, 1 Punkt Rückgabe der Liste.

Die Methode muss nicht wissen, in welchem Zustand sich ein Raum befindet: Das passende Verhalten wählt jede Raumanzeige über ihre polymorphe Referenz zustand selbst aus.

• Neue Klasse Aufbau, die von Anzeigezustand erbt und anzeigetext und minuteVergangen überschreibt (1 Punkt).

• Die Zustandswechsel festlegen: Beim Einrichten am Vortag setzt das Startprogramm des Info-Servers für jede Raumanzeige einmalig anzeige.setZustand(new Aufbau()); Aufbau.minuteVergangen wechselt zum Veranstaltungsbeginn mit r.setZustand(new Frei()) in den Zustand frei (1 Punkt).

• Raumanzeige und Raumverwaltung arbeiten nur mit dem abstrakten Typ Anzeigezustand und rufen dessen Methoden auf. Durch die späte Bindung wird automatisch die Implementierung der neuen Klasse ausgeführt (1 Punkt).