Übungsaufgaben zu Vererbung, abstrakten Klassen und Interfaces

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 „Vererbung, abstrakten Klassen
und Interfaces“.

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

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- UML-Klassendiagramm
- Vererbung
- abstrakte Klasse
- Interface
- Realisierung
- Sichtbarkeit
- Polymorphie
- Pseudocode

Kompetenzstufe: Kernkompetenz (alternativ: Basiskompetenz, Profilkompetenz, 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.

Beschreibung (2 Punkte): Bei der Vererbung wird eine spezialisierte Klasse (Unterklasse, Subklasse, abgeleitete Klasse) von einer allgemeineren Klasse (Oberklasse, Superklasse, Basisklasse) abgeleitet. Die Unterklasse übernimmt alle Attribute und Methoden der Oberklasse, ohne sie selbst noch einmal implementieren zu müssen, und kann eigene Attribute und Methoden ergänzen oder geerbte Methoden überschreiben. Zwischen Unter- und Oberklasse besteht eine „ist-ein“-Beziehung (ein Lastenrad ist ein Fahrrad).

Stellen im Quelltext (2 × 1 Punkt), z. B.:

• Die Attribute artikelnummer, bezeichnung, basispreis und rahmenhoehe sind in beiden Klassen identisch deklariert.

• Die Zuweisungen dieser vier Attribute in den Konstruktoren sind identisch.

• getBezeichnung() ist in beiden Klassen gleich implementiert.

• Beide Klassen haben die Methoden berechnePreis() und berechneVersandkosten() mit gleicher Signatur, aber unterschiedlicher Berechnung.

Bewertung (10 Punkte):

• je 1 Punkt für die vier Klassen mit Namen (4 Punkte)

• Fahrrad als abstrakt gekennzeichnet ({abstract}, kursiv oder <<abstract>>) (1 Punkt)

• berechnePreis(): Real in Fahrrad als abstrakte Methode (1 Punkt)

• gemeinsame Attribute, basispreis als protected (#), Konstruktor und getBezeichnung() nur in Fahrrad; berechneVersandkosten() als konkrete Methode in Fahrrad (1 Punkt)

• Unterklassen mit eigenen Attributen und eigenem Konstruktor (alle Parameter, auch die für die Oberklasse) (1 Punkt)

• überschriebene Methoden in den Unterklassen: berechnePreis() in allen drei, berechneVersandkosten() nur in Lastenrad (1 Punkt)

• drei Vererbungsbeziehungen mit hohlem Dreieck an Fahrrad (einzeln oder als Sammelpfeil) (1 Punkt)

Typische Fehler: geerbte Attribute in den Unterklassen wiederholen; berechneVersandkosten() in Stadtrad und EBike noch einmal eintragen, obwohl sie dort nicht anders berechnet wird; den Pfeil an der Unterklasse ansetzen; Konstruktoren in der Oberklasse für vererbt halten (Konstruktoren werden nicht vererbt, jede Unterklasse braucht einen eigenen).

Je Meldung 1 Punkt für die Erklärung und 1 Punkt für die Korrektur, 1 Punkt für die Begründung:

• Faltrad is not abstract and does not override abstract method berechnePreis(): berechnePreis() ist in Fahrrad abstrakt, steht dort also nur als Signatur ohne Rumpf. Jede Unterklasse, von der es Objekte geben soll, muss die Methode überschreiben; Faltrad tut das nicht. Korrektur: in Faltrad die Methode ergänzen, z. B. @Override public double berechnePreis() { return basispreis; }. (Die Klasse selbst abstrakt zu machen, wäre zwar übersetzbar, dann ließen sich aber keine Falträder anlegen.)

• Fahrrad is abstract; cannot be instantiated: Fahrrad ist als abstrakte Klasse modelliert. Sie ist nur die gemeinsame Vorlage, von ihr selbst lassen sich keine Objekte erzeugen; im Shop gibt es kein „Fahrrad an sich“. Korrektur: ein Objekt einer konkreten Unterklasse erzeugen, z. B. Fahrrad probe = new EBike("CSB-2207", "Teuto E-City", 2899.00, 50, 625);. Der Variablentyp darf Fahrrad bleiben.

• Vorteil: Eine Klasse mit abstrakter Methode muss selbst abstrakt sein, und nur vollständige Unterklassen werden konkret. So steht schon beim Übersetzen fest, dass sich für jedes Fahrradobjekt im Shop ein Preis berechnen lässt. Eine vergessene Preisberechnung fällt nicht erst auf, wenn eine Kundin bestellt.

Mit beiden Korrekturen übersetzt das Programm und gibt 3828.0 aus (749,00 € für das Faltrad, 2899,00 € + 180,00 € Akkuaufpreis für das E-Bike).

Auf private-Attribute kann nur die Klasse selbst zugreifen, nicht ihre Unterklassen. Die Unterklassen brauchen den Basispreis aber in ihrer eigenen Implementierung von berechnePreis(). Mit protected (#) dürfen die Klasse und alle Unterklassen zugreifen, andere Klassen weiterhin nicht – die Kapselung nach außen bleibt erhalten (2 Punkte).

Ebenfalls richtig (mit Begründung): basispreis bleibt private und Fahrrad bietet einen Getter getBasispreis() an, der protected oder public ist.

öffentlich Lastenrad(artikelnummer: String, bezeichnung: String, basispreis: Real,
                     rahmenhoehe: Integer, zuladung: Integer, regenverdeck: Boolean)
    Basisklassenkonstruktor Fahrrad(artikelnummer, bezeichnung, basispreis, rahmenhoehe) aufrufen
    this.zuladung := zuladung
    this.regenverdeck := regenverdeck
Ende Lastenrad

In Java:

public Lastenrad(String artikelnummer, String bezeichnung, double basispreis,
                 int rahmenhoehe, int zuladung, boolean regenverdeck) {
    super(artikelnummer, bezeichnung, basispreis, rahmenhoehe);
    this.zuladung = zuladung;
    this.regenverdeck = regenverdeck;
}

Bewertung: Methodenkopf mit allen Parametern (1 Punkt), Aufruf des Basisklassenkonstruktors mit den vier gemeinsamen Werten (2 Punkte), Setzen der eigenen Attribute (1 Punkt). Werden die geerbten Attribute direkt zugewiesen statt über den Basisklassenkonstruktor, gibt es für diesen Teil keine Punkte: Bis auf basispreis (protected) sind sie in Fahrrad private und für Lastenrad nicht zugreifbar; auch basispreis gehört in den Basisklassenkonstruktor.

öffentlich berechneVersandkosten(): Real
    Rückgabe berechneVersandkosten() der Basisklasse + 35,00
Ende berechneVersandkosten

In Java: return super.berechneVersandkosten() + 35.00; (mit @Override vor der Methode).

Bewertung: Methodenkopf mit gleicher Signatur wie in Fahrrad (1 Punkt), Aufruf der Basisklassenmethode (1 Punkt), Zuschlag und Rückgabe (1 Punkt). Wer 49,00 + 35,00 fest einträgt, erhält 1 Punkt: Das Ergebnis stimmt, aber eine Preisänderung bei der Spedition müsste dann an zwei Stellen gepflegt werden.

Ergänzung (2 Punkte): Klasse Kinderrad mit -laufradgroesse: Integer, eigenem Konstruktor, den überschriebenen Methoden berechnePreis(): Real (Pflicht, da abstrakt) und berechneVersandkosten(): Real (abweichende Versandkosten) sowie der Vererbungsbeziehung zu Fahrrad (1 Punkt Klasse, 1 Punkt Methoden und Beziehung).

Begründung (1 Punkt): Alle gemeinsamen Eigenschaften erbt Kinderrad von Fahrrad; das Abweichende wird nur in der neuen Klasse festgelegt. Die Oberklasse und die anderen Unterklassen kennen ihre Unterklassen nicht und bleiben unverändert – die Hierarchie ist für neue Fahrradarten erweiterbar, ohne vorhandenen, getesteten Code anzufassen.

Je Fehler 1 Punkt für die Erklärung und 1 Punkt für die Korrektur in der Skizze:

1. Durchgezogene Linie von Tuerschild zu Anzeige: Das ist die Notation der Vererbung. Ein Interface wird realisiert, nicht beerbt; richtig ist eine gestrichelte Linie mit hohlem Dreieck am Interface (in Java implements statt extends).

2. aktualisieren() ohne Parameter in Tuerschild: Die Signatur passt nicht zum Interface. So entstünde eine zusätzliche, überladene Methode, während aktualisieren(plan: Sessionplan) aus dem Interface unimplementiert bliebe. Korrektur: +aktualisieren(plan: Sessionplan).

3. istErreichbar() fehlt in Infomonitor: Eine Klasse, die ein Interface realisiert, muss alle seine Methoden implementieren. Sonst bleibt sie abstrakt, und es ließen sich keine Infomonitor-Objekte erzeugen. Korrektur: +istErreichbar(): Boolean ergänzen.

4. Aggregationen vom Sessionplan zu den konkreten Klassen: Das Attribut anzeigen hat den Typ Anzeige, und der Sessionplan soll mit jeder Anzeigeart arbeiten. Mit Beziehungen zu Tuerschild und Infomonitor müsste er für jede neue Anzeigeart geändert werden (enge Kopplung). Korrektur: eine einzige Beziehung zum Interface, hier eine Aggregation mit 1 am Sessionplan und 0..* an Anzeige. Der Sessionplan kennt dann nur den Vertrag, nicht die Geräte (lose Kopplung); eine Assoziation ist mit dieser Begründung ebenfalls richtig.

Je Anweisung 1 Punkt für die richtige Entscheidung mit Begründung:

1. wird übersetzt: Eine Variable vom Typ eines Interfaces darf auf ein Objekt jeder Klasse verweisen, die das Interface realisiert.

2. Fehler: Tuerschild und Infomonitor realisieren beide Anzeige, stehen aber in keiner Beziehung zueinander. Ein Infomonitor ist kein Türschild.

3. wird übersetzt: anmelden() erwartet eine Anzeige, und ein Infomonitor ist eine Anzeige.

4. Fehler: Der Compiler kennt von a1 nur den Typ Anzeige, und nicht jede Anzeige ist ein Türschild. Erst eine ausdrückliche Typumwandlung (Tuerschild) a1 würde übersetzt; mehr dazu im Artikel Polymorphie.

privat alleAnzeigenAktualisieren(): Liste von Anzeige
    stoerungen := neue leere Liste von Anzeige
    für jede a vom Typ Anzeige in anzeigen
        wenn a.istErreichbar() dann
            a.aktualisieren(this)
        sonst
            stoerungen.hinzufuegen(a)
        Ende wenn
    Ende für
    Rückgabe stoerungen
Ende alleAnzeigenAktualisieren

Bewertung: leere Liste anlegen (1 Punkt), Schleife über alle Elemente von anzeigen (1 Punkt), Prüfung mit istErreichbar() (1 Punkt), Aufruf aktualisieren(this) mit dem Sessionplan als Argument (1 Punkt), nicht erreichbare Anzeigen sammeln und die Liste zurückgeben (1 Punkt).

Bewertung (6 Punkte):

• Netzwerkgeraet als abstrakte Klasse gekennzeichnet (1 Punkt)

• Realisierung von Netzwerkgeraet zu Anzeige; Tuerschild und Infomonitor haben keine eigene Realisierung mehr (1 Punkt)

• Vererbung von Tuerschild und Infomonitor zu Netzwerkgeraet (1 Punkt)

• #ipAdresse, #vlanId und istErreichbar() nur in Netzwerkgeraet; ipAdresse nicht mehr in Infomonitor (1 Punkt)

• aktualisieren(plan: Sessionplan) in beiden Unterklassen, nicht in Netzwerkgeraet implementiert (1 Punkt)

• StreamEinblendung realisiert Anzeige direkt und implementiert beide Methoden; sie erbt nicht von Netzwerkgeraet (1 Punkt)

Netzwerkgeraet muss abstrakt sein, weil es aktualisieren() aus dem Interface übernimmt, aber nicht implementiert. Wer +{abstract} aktualisieren(plan: Sessionplan) zusätzlich in Netzwerkgeraet notiert, macht das ausdrücklich sichtbar – das ist ebenfalls richtig. Der Konstruktor des Türschilds erhält jetzt auch die IP-Adresse; die VLAN-ID kann fest 120 sein oder als weiterer Parameter übergeben werden.

Je Wunsch 1 Punkt für die passende Entscheidung und 1 Punkt für die Begründung, bei Wunsch 1 ein weiterer Punkt für die Beziehungen von Infomonitor (Vererbung zu Netzwerkgeraet und zusätzlich Realisierung von Dimmbar):

1. Interface, z. B. Dimmbar: Gemeinsam ist nur der Vertrag „lässt sich dimmen“, es gibt keine gemeinsame Implementierung und keine gemeinsamen Attribute. Infomonitor erbt schon von Netzwerkgeraet; eine zweite Oberklasse ist in Java oder C# nicht möglich, ein weiteres Interface dagegen schon. Buehnenlicht ist weder Anzeige noch Netzwerkgerät und kann Dimmbar trotzdem realisieren.

2. Netzwerkgeraet bleibt abstrakt: Von einer abstrakten Klasse lassen sich keine Objekte erzeugen, deshalb lehnt der Compiler die Anweisung ab. Würde Netzwerkgeraet konkret, müsste es auch aktualisieren() aus dem Interface implementieren, obwohl ein Netzwerkgerät „an sich“ nicht weiß, wie es etwas darstellen soll. Für den Test genügt ein Objekt einer konkreten Unterklasse wie Tuerschild; die geerbte, fertig implementierte Methode istErreichbar() lässt sich darüber prüfen.

3. Konkrete Klasse als Unterklasse von Tuerschild, z. B. FarbTuerschild: Auch eine konkrete Klasse kann Oberklasse sein. Das neue Schild übernimmt alles vom Türschild, überschreibt aktualisieren() und ergänzt die farbige Hervorhebung. Tuerschild bleibt konkret, weil es weiterhin normale Türschilder als Objekte gibt; ein Interface brächte die vorhandene Implementierung nicht mit.

Beispiel für eine Stellungnahme (3 Punkte): Der Vorschlag würde für Türschilder und Infomonitore funktionieren, passt aber nicht zur Stream-Einblendung. Sie müsste IP-Adresse, VLAN-ID und Ping erben, die sie gar nicht hat, oder der Sessionplan bräuchte doch wieder eine zweite Beziehung. Der Sessionplan wäre außerdem an eine Klasse mit Implementierung gebunden statt an einen schlanken Vertrag. Das Interface trennt den Vertrag („kann aktualisiert werden“) von der gemeinsamen Implementierung für netzwerkfähige Geräte. Ich würde es deshalb beibehalten.

Eine Gegenposition ist nur mit tragfähiger Begründung richtig, z. B.: Entfällt die Stream-Einblendung und sind sicher keine weiteren Anzeigearten geplant, reicht für ein eintägiges Barcamp auch die einfachere Struktur (Prinzip „YAGNI“).

Bewertung (8 Punkte):

• Interface mit <<interface>> und beiden Methodensignaturen (2 Punkte)

• Erinnerungsdienst mit Attributen (inkl. Standardwert), Konstruktor und beiden Methoden mit vollständiger Signatur (2 Punkte)

• EMailKanal und PushKanal mit Attribut, Konstruktor und den beiden implementierten Methoden (2 Punkte)

• zwei Realisierungen (gestrichelt, hohles Dreieck am Interface) (1 Punkt)

• Beziehung Erinnerungsdienst – Benachrichtigungskanal (Aggregation, Assoziation oder Komposition) (1 Punkt)

Hinweis: Ob die Referenz kanal zusätzlich als Attribut eingetragen wird, ist Geschmackssache – hier verlangt sie das Pflichtenheft. Multiplizitäten sind nicht gefordert; 0..1 drückt aus, dass anfangs noch kein Kanal gesetzt sein kann.

öffentlich erinnern(b: Buchung): Boolean
    wenn kanal = null dann
        Rückgabe falsch
    Ende wenn
    text := "RatzFahrt: Deine Fahrt startet " + b.getAbfahrt() + " ab " + b.getHaltepunkt() + "."
    Rückgabe kanal.senden(b.getMitfahrer(), text)
Ende erinnern

Bewertung: Prüfung auf fehlenden Kanal mit Rückgabe falsch (1 Punkt), Text aus den Buchungsdaten zusammensetzen (1 Punkt), Aufruf von senden() auf dem Interface-Objekt kanal mit dem Mitfahrer als Empfänger (1 Punkt), Rückgabe des Ergebnisses von senden() (1 Punkt).

Der Erinnerungsdienst weiß nicht, ob gerade eine E-Mail oder eine Push-Nachricht verschickt wird – er ruft nur die Methode des Vertrags auf.

dienst := new Erinnerungsdienst()
dienst.setKanal(new EMailKanal("ratzfahrt@rrb.example"))

dienst.setKanal(new PushKanal("https://push.ratzfahrt.example/v1"))
dienst.erinnern(buchungLukas)

Bewertung: Erzeugen des Dienstes und Setzen des E-Mail-Kanals (1 Punkt), Austausch des Kanals über setKanal() mit einem neuen PushKanal-Objekt (1 Punkt), Aufruf von erinnern() mit der Buchung (1 Punkt).

Eleganter wäre es, den bevorzugten Kanal je Nutzer*in zu speichern; das ist hier aber nicht gefragt.

Je Fehler 2 Punkte (1 Punkt Erläuterung, 1 Punkt Korrektur):

1. extends statt implements: Benachrichtigungskanal ist ein Interface. Von einem Interface wird nicht geerbt, es wird realisiert. Korrektur: public class TestKanal implements Benachrichtigungskanal.

2. getName() fehlt: Eine Klasse, die ein Interface realisiert, muss alle seine abstrakten Methoden implementieren, sonst ist sie selbst abstrakt (und müsste so gekennzeichnet werden). Korrektur: public String getName() { return "Test"; } ergänzen.

3. Interface instanziiert: new Benachrichtigungskanal() ist nicht möglich, weil von Interfaces (wie von abstrakten Klassen) keine Objekte erzeugt werden können. Korrektur: ein Objekt einer realisierenden Klasse erzeugen, z. B. Benachrichtigungskanal standard = new TestKanal(""); – der Variablentyp darf das Interface bleiben.

Ebenfalls als Hinweis richtig: Das Attribut protokoll sollte für den Test über einen Getter auslesbar sein, sonst kann der Test das Ergebnis nicht prüfen.

Mögliche Begründungen (3 Punkte, je nach Tiefe):

• Die Kanäle haben keine gemeinsame Implementierung und keine gemeinsamen Attribute – E-Mail und Push werden völlig unterschiedlich versendet. Es gibt also nichts zu vererben, nur einen gemeinsamen Vertrag.

• Der Erinnerungsdienst hängt nur vom Vertrag ab (lose Kopplung). Neue Kanäle können ergänzt und zur Laufzeit über setKanal() getauscht werden, ohne den Erinnerungsdienst zu ändern.

• Eine Klasse kann beliebig viele Interfaces realisieren, aber nur von einer Klasse erben. Ein PushKanal könnte so z. B. zusätzlich von einer vorhandenen Klasse für HTTP-Verbindungen erben.

• Für Tests lässt sich leicht eine Attrappe (wie TestKanal) einsetzen.