Übungsaufgaben zum Entwurfsmuster Fabrikmethode

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 „Entwurfsmuster Fabrikmethode“.

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

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- Fabrikmethode
- Entwurfsmuster
- Erzeugungsmuster
- Factory Method
- statische Fabrikmethode
- Polymorphie
- UML-Klassendiagramm
- Singleton

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.

Je Zeile 0,5 Punkte für die Klasse(n) und 1 Punkt für einen passenden Beleg:

Andere passende Belege sind ebenfalls richtig.

• Kategorie (1 Punkt): Erzeugungsmuster (creational pattern).

• Zwei weitere (je 0,5 Punkte): Singleton, Abstrakte Fabrik (Abstract Factory), Erbauer (Builder), Prototyp (Prototype).

Bewertung:

• 2 Punkte für Sprachaktivitaet: erbt von Aktivitaet (1) und überschreibt #erzeugeBestaetigung(b: Benutzer): Teilnahmebestaetigung, die eine Sprachbestaetigung zurückgibt (1).

• 2 Punkte für Sprachbestaetigung: erbt von Teilnahmebestaetigung (1), erhält einen Konstruktor und überschreibt +getText(): String mit den beiden Sprachen und dem Hinweis (1).

• 1 Punkt für die unveränderte Methode: anmelden() in Aktivitaet bleibt gleich, weil sie laut ADR-017 nur die Fabrikmethode aufruft und mit dem abstrakten Typ Teilnahmebestaetigung arbeitet („no change to anmelden()“).

Das Diagramm zeigt die Ergänzung im Klassenmodell. Eine Zeichnung ist nicht gefordert.

Die «Create»-Abhängigkeit von Sprachaktivitaet zu Sprachbestaetigung ist sinnvoll, aber nicht gefordert. Ein Attribut für die Sprachen (z. B. -sprachen: String [2] in Sprachaktivitaet) ist richtig, aber ebenfalls nicht gefordert.

JANA Pseudo-Pascal Pseudo-Pascal (deutsch) Pseudo-Python all none

Teilnahmebestaetigung anmelden(Benutzer b) {
    if (b.getAlter() < mindestalter) {
        return null
    }
    Teilnahmebestaetigung bestaetigung = erzeugeBestaetigung(b)
    bestaetigung.senden()
    return bestaetigung
}

FUNCTION anmelden(b: Benutzer) : Teilnahmebestaetigung
    if (b.getAlter() < mindestalter) then
        RETURN nil
    end if
    bestaetigung: Teilnahmebestaetigung := erzeugeBestaetigung(b)
    bestaetigung.senden()
    RETURN bestaetigung
END anmelden

Funktion anmelden(b: Benutzer): Teilnahmebestaetigung
    wenn b.getAlter() < mindestalter dann
        Rückgabe null
    Ende wenn
    bestaetigung: Teilnahmebestaetigung := erzeugeBestaetigung(b)
    bestaetigung.senden()
    Rückgabe bestaetigung
Ende anmelden

def anmelden(self, b):  # Rückgabe: Teilnahmebestaetigung
    if b.getAlter() < self.mindestalter:
        return None
    # Ende if
    bestaetigung = self.erzeugeBestaetigung(b)
    bestaetigung.senden()
    return bestaetigung
# Ende anmelden

Bewertung:

• 1 Punkt Altersprüfung mit Rückgabe null

• 2 Punkte Aufruf der Fabrikmethode mit Übergabe von b und Speichern in einer Variablen vom Typ Teilnahmebestaetigung

• 1 Punkt Aufruf senden() am erzeugten Objekt

• 1 Punkt Rückgabe der Bestätigung

Kein Punkt für den Aufruf eines Konstruktors (new Naturbestaetigung(...)) in anmelden(): Genau das soll die Fabrikmethode vermeiden.

JANA Pseudo-Pascal Pseudo-Pascal (deutsch) Pseudo-Python all none

Teilnahmebestaetigung erzeugeBestaetigung(Benutzer b) {
    return new Sprachbestaetigung(b, this)
}

FUNCTION erzeugeBestaetigung(b: Benutzer) : Teilnahmebestaetigung
    RETURN new Sprachbestaetigung(b, this)
END erzeugeBestaetigung

Funktion erzeugeBestaetigung(b: Benutzer): Teilnahmebestaetigung
    Rückgabe new Sprachbestaetigung(b, this)
Ende erzeugeBestaetigung

def erzeugeBestaetigung(self, b):  # Rückgabe: Teilnahmebestaetigung
    return Sprachbestaetigung(b, self)
# Ende erzeugeBestaetigung

• 1 Punkt Objekterzeugung einer Sprachbestaetigung

• 1 Punkt Rückgabe

• 1 Punkt Erläuterung: Mit this (in Pseudo-Python self) übergibt die Aktivität sich selbst. Die Bestätigung kennt damit „ihre“ Aktivität und kann Titel, Treffpunkt, Beginn und die Sprachen für den Text abfragen.

Je Fehler 1 Punkt Beschreibung, 1 Punkt Korrektur:

1. Objekt einer abstrakten Klasse: In Kulturaktivitaet.erzeugeBestaetigung() wird new Teilnahmebestaetigung(...) aufgerufen. Von der abstrakten Klasse lassen sich keine Objekte erzeugen (Übersetzungsfehler). Korrektur: return new Kulturbestaetigung(b, this);

2. Kein gemeinsamer Obertyp: Kulturbestaetigung erbt nicht von Teilnahmebestaetigung. Ihre Objekte können weder t zugewiesen noch von der Fabrikmethode zurückgegeben werden (Übersetzungsfehler, genau die Einschränkung aus ADR-017). Korrektur: public class Kulturbestaetigung extends Teilnahmebestaetigung, im Konstruktor super(b, a); aufrufen und getText() überschreiben (@Override).

3. Fallunterscheidung und Konstruktoraufruf im Erzeuger: anmelden() prüft mit instanceof die konkrete Unterklasse und erzeugt die Kulturbestätigung selbst. Damit kennt die Oberklasse wieder konkrete Klassen und muss für jede neue Kategorie geändert werden – das Muster wird ausgehebelt. Korrektur: Die if-Anweisung entfernen; anmelden() ruft immer t = erzeugeBestaetigung(b); auf, die Entscheidung trifft die überschreibende Methode in Kulturaktivitaet.

• abstrakt (1 Punkt): Aktivitaet kann nicht wissen, welche Bestätigung passt. Die abstrakte Methode zwingt jede (nicht abstrakte) Unterklasse, die Fabrikmethode zu implementieren; eine neue Kategorie ohne Bestätigung fällt schon beim Übersetzen auf. Zugleich muss Aktivitaet dadurch selbst abstrakt sein; es gibt also keine „Aktivität ohne Kategorie“.

• protected (1 Punkt): Die Methode ist ein internes Hilfsmittel von anmelden(). Von außen soll niemand eine Bestätigung erzeugen, ohne dass das Alter geprüft und die Bestätigung versendet wird. Unterklassen müssen sie aber sehen und überschreiben können.

• Standardimplementierung (1 Punkt): wenn es eine sinnvolle allgemeine Bestätigung gibt (z. B. eine StandardBestaetigung mit Titel, Treffpunkt und Beginn), die die meisten Kategorien nutzen können. Dann überschreiben nur Kategorien mit Besonderheiten die Methode; der Erzeuger ist in diesem Fall eine konkrete Klasse.

Je Nachteil 2 Punkte, z. B.:

• Redundante Fallunterscheidungen: Dieselbe switch-Struktur über art steht in mehreren Methoden. Für die Pendelangebote muss jede dieser Methoden geändert werden; wird eine vergessen, ist das Verhalten widersprüchlich.

• Fehler fallen nicht auf: Kommt eine Zeile mit 'Pendel' an, bevor der Code angepasst ist, liefert kachelText() still einen leeren Text und farbe() Weiß – auf dem Monitor erscheint eine leere weiße Kachel, ohne Fehlermeldung. Tippfehler in den Zeichenketten fallen ebenfalls erst zur Laufzeit auf.

• Unnötige Attribute: Jedes Objekt trägt alle Attribute, auch wenn sie für seine Art keine Bedeutung haben (plaetze bei Gesuchen, künftig wochentage bei allen).

• Geprüfter Code wird geändert: Jede Erweiterung ändert die bestehende, getestete Klasse statt nur neuen Code hinzuzufügen (Verstoß gegen das Offen-geschlossen-Prinzip); die Klasse wird mit jeder Art länger.

Bewertung:

• 2 Punkte Oberklasse: MonitorEintrag abstrakt, ohne Attribut art, mit den gemeinsamen Attributen und den abstrakten Methoden kachelText() und farbe()

• 1 Punkt statische Methode erzeuge(z: Zeile): MonitorEintrag (unterstrichen bzw. {static})

• 3 Punkte Unterklassen für Angebote, Gesuche und Pendelangebote, jeweils mit ihren eigenen Attributen (plaetze, wochentage) und den Methoden, die sie überschreiben

• 1 Punkt Generalisierungen

• 1 Punkt Begründung der Entscheidung für das Pendelangebot

Richtig ist auch, PendelEintrag direkt von MonitorEintrag erben zu lassen; dann braucht die Klasse ein eigenes Attribut plaetze und eine eigene farbe(). Die Vererbung von AngebotEintrag vermeidet diese Doppelung. Das Attribut plaetze kann auch in der Oberklasse bleiben.

Ursachen (2 Punkte): Jonas prüft nur auf "Gesuch"; alles andere wird zu einem AngebotEintrag. Ein Pendelangebot ist damit ein gewöhnliches Angebot, dessen kachelText() die Wochentage nicht kennt (1 Punkt). Auch jede unbekannte Art landet im letzten Zweig und wird still als Angebot angezeigt, statt aufzufallen (1 Punkt).

Korrigierte Fassung (3 Punkte):

JANA Pseudo-Pascal Pseudo-Pascal (deutsch) Pseudo-Python all none

static MonitorEintrag erzeuge(Zeile z) {
    switch (z.getText("art")) {
        case "Angebot":
            return new AngebotEintrag(z)
        case "Gesuch":
            return new GesuchEintrag(z)
        case "Pendel":
            return new PendelEintrag(z)
        default:
            return null
    }
}

static FUNCTION erzeuge(z: Zeile) : MonitorEintrag
    case z.getText("art") of
        "Angebot":
            RETURN new AngebotEintrag(z)
        "Gesuch":
            RETURN new GesuchEintrag(z)
        "Pendel":
            RETURN new PendelEintrag(z)
        else
            RETURN nil
    end case
END erzeuge

statisch Funktion erzeuge(z: Zeile): MonitorEintrag
    falls z.getText("art")
        "Angebot":
            Rückgabe new AngebotEintrag(z)
        "Gesuch":
            Rückgabe new GesuchEintrag(z)
        "Pendel":
            Rückgabe new PendelEintrag(z)
        sonst:
            Rückgabe null
    Ende falls
Ende erzeuge

def erzeuge(z):  # statisch, Rückgabe: MonitorEintrag
    match z.getText("art"):
        case "Angebot":
            return AngebotEintrag(z)
        case "Gesuch":
            return GesuchEintrag(z)
        case "Pendel":
            return PendelEintrag(z)
        case _:
            return None
    # Ende match
# Ende erzeuge

Als Struktogramm mit verschachtelten Verzweigungen (eine Fallauswahl mit vier Spalten ist ebenso richtig):

Bewertung:

• 1 Punkt eigener Fall für "Pendel" mit PendelEintrag

• 1 Punkt Angebote und Gesuche nur bei passender Art

• 1 Punkt Rückgabe null für jede andere Art

In Java würde man für eine unbekannte Art oft eine Ausnahme werfen (throw new IllegalArgumentException(...)) oder den Fehler protokollieren; Bleibt es bei null, muss der Player diesen Wert vor dem Hinzufügen abfangen.

• Anweisung (1 Punkt): eintraege.add(MonitorEintrag.erzeuge(zeile)); – Aufruf über den Klassennamen, weil die Methode statisch ist (ggf. mit Prüfung auf null).

• Maßnahmen (je 1 Punkt, zwei davon):

  • MonitorEintrag ist abstrakt, new MonitorEintrag(zeile) ist also nicht mehr möglich.

  • Die Konstruktoren der Unterklassen sind nicht öffentlich, sondern paketsichtbar (~) oder protected; MonitorEintrag mit der Fabrikmethode und die Unterklassen liegen im selben Paket, der Player in einem anderen.

  • Der Rückgabetyp ist MonitorEintrag: Der Player kennt die Unterklassen gar nicht und braucht sie nicht.

• Aufrufkette (1 Punkt): Die Monitorsteuerung ruft erstelleKachel(e) an ihrem Fabrikobjekt auf. Die Methode ist in Kachelfabrik implementiert und wird geerbt. Sie fragt e.getArt() ab (Ergebnis "Gesuch") und ruft neueKachel("Gesuch") auf.

• Wer entscheidet (1 Punkt): Weil das Fabrikobjekt eine Kompaktfabrik ist, läuft deren überschriebene neueKachel (späte Bindung). Sie wertet die Art gar nicht aus und erzeugt immer eine KompaktKachel.

• Ergebnis (1 Punkt): erstelleKachel ruft an dieser Kachel befuellen(e) auf und gibt eine befüllte KompaktKachel an die Monitorsteuerung zurück. Die Monitorsteuerung kennt dabei nur den Typ Kachel.

Ergänzungen im Entwurf (2 Punkte): eine Klasse Hochkantfabrik, die von Kachelfabrik erbt und #neueKachel(art: String): Kachel überschreibt (1 Punkt); eine Klasse HochkantAngebotKachel, die von Kachel erbt und zeichnen() überschreibt, dazu «Create»-Abhängigkeiten von Hochkantfabrik zu HochkantAngebotKachel und KompaktKachel (1 Punkt). Monitorsteuerung, Kachelfabrik und die übrigen Kacheln bleiben unverändert.

Methode (2 Punkte):

JANA Pseudo-Pascal Pseudo-Pascal (deutsch) Pseudo-Python all none

Kachel neueKachel(String art) {
    if (art == "Angebot") {
        return new HochkantAngebotKachel()
    }
    return new KompaktKachel()
}

FUNCTION neueKachel(art: String) : Kachel
    if art = "Angebot" then
        RETURN new HochkantAngebotKachel()
    end if
    RETURN new KompaktKachel()
END neueKachel

Funktion neueKachel(art: string): Kachel
    wenn art = "Angebot" dann
        Rückgabe new HochkantAngebotKachel()
    Ende wenn
    Rückgabe new KompaktKachel()
Ende neueKachel

def neueKachel(self, art):  # Rückgabe: Kachel
    if art == "Angebot":
        return HochkantAngebotKachel()
    # Ende if
    return KompaktKachel()
# Ende neueKachel

Bewertung: 1 Punkt Verzweigung über art, 1 Punkt beide Rückgaben mit Objekterzeugung. Weil getArt() für Pendelangebote "Angebot" liefert, braucht es keinen eigenen Fall dafür.

Je Unterschied 2 Punkte, z. B.:

• Wer entscheidet über die Klasse? Bei den Kachelfabriken entscheidet die Unterklasse des Erzeugers (Grossformatfabrik oder Kompaktfabrik), welche Kachel entsteht; erstelleKachel() in der Oberklasse kennt nur Kachel. Bei erzeuge() trifft eine einzige Methode die Entscheidung über eine Mehrfachauswahl, eine Erzeuger-Hierarchie gibt es nicht.

• Objektmethode vs. Klassenmethode: neueKachel() ist eine (abstrakte, überschreibbare) Methode, die an einem Fabrikobjekt aufgerufen wird; welche Implementierung läuft, entscheidet sich zur Laufzeit (späte Bindung). erzeuge() ist statisch, wird über den Klassennamen aufgerufen und kann nicht überschrieben werden.

• Erweiterung: Für einen neuen Monitortyp (z. B. Hochformat) wird bei den Kachelfabriken nur eine neue Fabrik mit ihren Kacheln ergänzt, Monitorsteuerung und erstelleKachel() bleiben unverändert. Für eine neue Eintragsart muss dagegen erzeuge() geändert werden.

• Einordnung: Die Kachelfabriken setzen das GoF-Muster Fabrikmethode um; die statische Methode ist eine statische Fabrikmethode (kein GoF-Muster, sondern ein Programmieridiom).

• Singleton (1,5 Punkte): Vorteil: Die Klasse selbst stellt sicher, dass es nur ein Objekt gibt (privater Konstruktor, statische Zugriffsmethode); jede Klasse kommt ohne zusätzliche Parameter an die Verbindung. Nachteil: Die Verbindung ist ein globaler Zugriffspunkt. Welche Klassen sie nutzen, sieht man den Signaturen nicht an, und für Tests lässt sie sich schwer durch eine Testverbindung ersetzen.

• Übergeben (1,5 Punkte): Vorteil: Abhängigkeiten stehen sichtbar im Konstruktor, und für Tests kann man leicht eine andere Verbindung übergeben. Nachteil: Dass es nur ein Objekt gibt, beruht auf Disziplin; mehrere Konstruktoren erhalten einen zusätzlichen Parameter.

• Entscheidung (1 Punkt), z. B.: Für den kleinen Player ist das Übergeben gut beherrschbar und besser testbar; wer viele Klassen hat, die die Verbindung brauchen, kann den Singleton wählen. Jede schlüssig begründete Entscheidung ist richtig.