Entwurfsmuster Fabrikmethode (Factory Method)

Entwurfsmuster Fabrikmethode (Factory Method)

https://bildung.social/@oerinformatik/

https://oer-informatik.de/entwurfsmuster-fabrikmethode

Fabrikmethode, Factory Method, Entwurfsmuster, Erzeugungsmuster, Statische Fabrikmethode, Abstrakte Fabrik, Singleton, UML-Klassendiagramm, Polymorphie, Offen-geschlossen-Prinzip

tl/dr; (ca. 20 min Lesezeit): Die Fabrikmethode ist ein Erzeugungsmuster: Statt an vielen Stellen mit new konkrete Klassen zu erzeugen, ruft eine Klasse eine überschreibbare Methode auf, und ihre Unterklassen entscheiden, welches Objekt entsteht. Der Artikel erklärt Rollen, Klassendiagramm und Pseudocode, die wichtige Einschränkung (gemeinsamer Obertyp der Produkte), die parametrisierte und die statische Fabrikmethode und zeigt typische Fehler in Aufgaben [AI-Assisted]. (Zuletzt geändert am 28.10.2026)

Dieser Artikel ist Teil einer Artikelreihe zur objektorientierten Modellierung: Klassendiagramm / Vererbung / Abstrakte Klassen und Interfaces / Polymorphie / Entwurfsmuster / Fabrikmethode / Übungsaufgaben zur Fabrikmethode

Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast. Hier klicken, um Kann-Liste ein- oder auszublenden

Im Artikel Polymorphie verschwinden lange Fallunterscheidungen, weil jede Variante eine eigene Unterklasse bekommt. Eine Frage bleibt dabei offen: Wer erzeugt eigentlich die Objekte? Irgendwo im Programm muss doch wieder stehen if (art == "pdf") bericht = new PdfBericht();. Genau für diese Stelle gibt es Erzeugungsmuster – und das bekannteste davon ist die Fabrikmethode.

Das Problem: new an der falschen Stelle

Ein Objekt mit new zu erzeugen, ist die engste Bindung, die eine Klasse an eine andere eingehen kann: Wer new PdfBericht() schreibt, kennt die konkrete Klasse PdfBericht und ist von ihr abhängig. Solange es nur eine Variante gibt, ist das kein Problem. Sobald aber neue Varianten hinzukommen, muss jede Stelle mit einem new (und die Fallunterscheidung drumherum) geändert werden.

Beispiel: Eine Wetterstations-App exportiert Messwerte als Bericht. Zuerst gab es nur PDF, dann kam CSV dazu, nun wird HTML gewünscht. Steht die Erzeugung mitten in der Exportlogik, wird diese Logik bei jeder neuen Variante angefasst – obwohl sich am eigentlichen Ablauf (Bericht anlegen, Zeilen eintragen, speichern) nichts ändert.

Die Idee der Fabrikmethode

Die „Gang of Four“ (Gamma, Helm, Johnson, Vlissides) beschreibt den Zweck der Fabrikmethode so:

„Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.“

Sinngemäß: Eine Klasse legt fest, dass ein Objekt erzeugt wird, aber ihre Unterklassen entscheiden, welches. Daraus ergeben sich die drei Kernaspekte, die Du erläutern können solltest:

1. Schnittstelle zur Erzeugung in der Oberklasse: Die Oberklasse (der Erzeuger) deklariert eine Methode, die ein Objekt erzeugt und zurückgibt – die Fabrikmethode. Meist ist sie abstrakt.

2. Konstruktoraufruf wird in eine Methode verlagert: Wo bisher new KonkreteKlasse() stand, steht jetzt ein Aufruf der Fabrikmethode. Der Code, der das Objekt benutzt, kennt nur noch den abstrakten Typ.

3. Unterklassen überschreiben die Fabrikmethode: Jede Unterklasse des Erzeugers implementiert die Fabrikmethode und gibt ein Objekt „ihrer“ konkreten Produktklasse zurück. So lässt sich der Typ der erzeugten Objekte ändern, ohne den aufrufenden Code zu ändern.

Die Fabrikmethode gehört zu den Erzeugungsmustern (creational patterns), also zu den Mustern, die regeln, wie und von wem Objekte erzeugt werden (siehe Kategorien von Entwurfsmustern).

Rollen und Klassendiagramm

Das Muster besteht aus zwei parallelen Vererbungshierarchien: einer für die Erzeuger und einer für die Produkte.

Zur Notation im UML-Klassendiagramm (UML 2.5.1):

• Generalisierung (durchgezogene Linie, hohles Dreieck an der Oberklasse) von den konkreten Erzeugern zum Erzeuger und – ist das Produkt eine abstrakte Klasse – von den konkreten Produkten zum Produkt. Ist das Produkt ein Interface, ist es eine Realisierung (gestrichelte Linie, hohles Dreieck).

• Die Fabrikmethode steht im Erzeuger kursiv bzw. mit {abstract} und wird in jedem konkreten Erzeuger mit gleicher Signatur erneut notiert. Häufig ist sie protected (#), weil nur der Erzeuger selbst und seine Unterklassen sie aufrufen sollen.

• Die Erzeugungsbeziehung wird als Abhängigkeit mit dem Stereotyp «Create» (gestrichelter Pfeil vom Erzeuger zum erzeugten Produkt) dargestellt. Manche Darstellungen zeigen stattdessen eine gerichtete Assoziation vom Erzeuger zum Produkt (z. B. mit Multiplizität 1 zu *); entscheidend ist in beiden Fällen die Richtung vom Erzeuger zum Produkt. Eine Assoziation ist allerdings nur angebracht, wenn der Erzeuger seine Produkte dauerhaft kennt, sie also z. B. in einer Liste verwaltet; erzeugt er sie nur und gibt sie zurück, genügt eine Abhängigkeit mit dem Stereotyp «Create» (gestrichelter Pfeil) wie im Strukturbild oben.

Ein Beispiel: Berichte exportieren

Zurück zur Wetterstation. Die abstrakte Klasse Berichtsexport übernimmt die Rolle des Erzeugers, Bericht ist das Produkt.

In Java:

public abstract class Berichtsexport {

    // nutzt die Fabrikmethode – kennt nur den abstrakten Typ Bericht
    public Bericht exportiere(List<Messwert> werte) {
        Bericht bericht = erzeugeBericht();      // statt new PdfBericht()
        for (Messwert w : werte) {
            bericht.zeileHinzufuegen(w.toString());
        }
        return bericht;
    }

    // die Fabrikmethode
    protected abstract Bericht erzeugeBericht();
}

public class PdfExport extends Berichtsexport {
    @Override
    protected Bericht erzeugeBericht() {
        return new PdfBericht();
    }
}

public class CsvExport extends Berichtsexport {
    @Override
    protected Bericht erzeugeBericht() {
        return new CsvBericht();
    }
}

Der Client wählt einmal den passenden Erzeuger und arbeitet dann nur noch mit den abstrakten Typen:

Berichtsexport export = new CsvExport();
Bericht b = export.exportiere(messwerteOktober);
b.speichern("wetter-oktober.csv");

In Pseudocode genügen für die beiden Methoden wenige Zeilen. Entscheidend sind der Aufruf der Fabrikmethode, die Weiterarbeit mit dem Ergebnis und die Rückgabe:

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

Bericht exportiere(Messwert werte[]) {
    Bericht bericht = erzeugeBericht()
    for (w ∈ werte) {
        bericht.zeileHinzufuegen(w.toString())
    }
    return bericht
}

Bericht erzeugeBericht() {  // in PdfExport
    return new PdfBericht()
}

FUNCTION exportiere(werte: array of Messwert) : Bericht
    bericht: Bericht := erzeugeBericht()
    foreach w in werte
        bericht.zeileHinzufuegen(w.toString())
    next w
    RETURN bericht
END exportiere

FUNCTION erzeugeBericht() : Bericht  // in PdfExport
    RETURN new PdfBericht()
END erzeugeBericht

Funktion exportiere(werte: Messwert[]): Bericht
    bericht: Bericht := erzeugeBericht()
    für jedes w in werte
        bericht.zeileHinzufuegen(w.toString())
    Ende für
    Rückgabe bericht
Ende exportiere

Funktion erzeugeBericht(): Bericht  // in PdfExport
    Rückgabe new PdfBericht()
Ende erzeugeBericht

def exportiere(self, werte):  # werte: Liste von Messwert, Rückgabe: Bericht
    bericht = self.erzeugeBericht()
    for w in werte:
        bericht.zeileHinzufuegen(w.toString())
    # Ende for
    return bericht
# Ende exportiere

def erzeugeBericht(self):  # in PdfExport, Rückgabe: Bericht
    return PdfBericht()
# Ende erzeugeBericht

Über die Reiter wechselst Du zwischen vier Pseudocode-Notationen. Die Notationen sind im Artikel Algorithmen mit Pseudocode dokumentieren beschrieben.

Soll später ein HTML-Bericht dazukommen, entstehen genau zwei neue Klassen: HtmlBericht (erbt von Bericht, implementiert speichern()) und HtmlExport (erbt von Berichtsexport, überschreibt erzeugeBericht() mit Rückgabe new HtmlBericht()). An Berichtsexport, Bericht und den vorhandenen Unterklassen ändert sich nichts. Das ist das Offen-geschlossen-Prinzip (open-closed principle): offen für Erweiterungen, geschlossen für Änderungen.

Die Einschränkung: Alle Produkte brauchen einen gemeinsamen Obertyp

Damit das funktioniert, gilt eine wichtige Einschränkung für die Klassenstruktur: Die Unterklassen dürfen nur dann unterschiedliche Produkte zurückgeben, wenn alle Produkte eine gemeinsame Basisklasse haben oder ein gemeinsames Interface implementieren. Außerdem muss die Fabrikmethode im Erzeuger diesen Obertyp als Rückgabetyp haben.

Der Grund: Eine überschreibende Methode muss dieselbe Signatur (Name und Parameterliste) haben wie die überschriebene, und ihr Rückgabetyp muss derselbe oder ein Untertyp davon sein (kovarianter Rückgabetyp, covariant return type). Gibt Berichtsexport.erzeugeBericht() einen Bericht zurück, kann PdfExport.erzeugeBericht() nur Objekte liefern, die ebenfalls vom Typ Bericht sind – also Objekte einer Unterklasse von Bericht. Eine Klasse HtmlBericht, die nicht von Bericht erbt, ließe sich nicht zurückgeben (Übersetzungsfehler). Und nur weil alle Produkte vom Typ Bericht sind, kann exportiere() sie einheitlich behandeln (bericht.zeileHinzufuegen(...)): Hier wirkt Polymorphie mit später Bindung (late binding).

Für das Produkt kommt meist eine abstrakte Klasse in Frage, wenn alle Produkte gemeinsame Attribute oder bereits fertige Methoden teilen (zeilen, zeileHinzufuegen()), sonst ein Interface. Von beiden lassen sich keine Objekte direkt erzeugen – ein new Bericht() ist also nicht möglich (siehe Abstrakte Klassen und Interfaces).

Parametrisierte Fabrikmethode

Häufig erzeugt ein konkreter Erzeuger nicht nur eine, sondern mehrere Produktarten. Dann bekommt die Fabrikmethode einen Übergabeparameter, der die Art bestimmt, und wählt das Produkt mit einer Mehrfachauswahl aus. Beispiel: Die Wetterstation unterscheidet Tages- und Monatsberichte, jeweils als PDF:

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

Bericht erzeugeBericht(String art) {  // in PdfExport
    switch (art) {
        case "Tag":
            return new PdfTagesbericht()
        case "Monat":
            return new PdfMonatsbericht()
        default:
            return null
    }
}

FUNCTION erzeugeBericht(art: String) : Bericht  // in PdfExport
    case art of
        "Tag":
            RETURN new PdfTagesbericht()
        "Monat":
            RETURN new PdfMonatsbericht()
        else
            RETURN nil
    end case
END erzeugeBericht

Funktion erzeugeBericht(art: string): Bericht  // in PdfExport
    falls art
        "Tag":
            Rückgabe new PdfTagesbericht()
        "Monat":
            Rückgabe new PdfMonatsbericht()
        sonst:
            Rückgabe null
    Ende falls
Ende erzeugeBericht

def erzeugeBericht(self, art):  # in PdfExport, Rückgabe: Bericht
    match art:
        case "Tag":
            return PdfTagesbericht()
        case "Monat":
            return PdfMonatsbericht()
        case _:
            return None
    # Ende match
# Ende erzeugeBericht

Gleichwertig ist die Schreibweise mit einer Hilfsvariablen und einer gemeinsamen Rückgabe am Ende:

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

Bericht erzeugeBericht(String art) {
    Bericht bericht = null
    switch (art) {
        case "Tag":
            bericht = new PdfTagesbericht()
        case "Monat":
            bericht = new PdfMonatsbericht()
    }
    return bericht
}

FUNCTION erzeugeBericht(art: String) : Bericht
    bericht: Bericht := nil
    case art of
        "Tag":
            bericht := new PdfTagesbericht()
        "Monat":
            bericht := new PdfMonatsbericht()
    end case
    RETURN bericht
END erzeugeBericht

Funktion erzeugeBericht(art: string): Bericht
    bericht: Bericht := null
    falls art
        "Tag":
            bericht := new PdfTagesbericht()
        "Monat":
            bericht := new PdfMonatsbericht()
    Ende falls
    Rückgabe bericht
Ende erzeugeBericht

def erzeugeBericht(self, art):  # Rückgabe: Bericht
    bericht = None
    match art:
        case "Tag":
            bericht = PdfTagesbericht()
        case "Monat":
            bericht = PdfMonatsbericht()
    # Ende match
    return bericht
# Ende erzeugeBericht

Worauf es ankommt:

• Selektor der Mehrfachauswahl ist der Parameter (art).

• Je Fall wird mit new das passende konkrete Produkt erzeugt und zurückgegeben.

• Der Rückgabetyp bleibt der gemeinsame Obertyp (Bericht).

• Für einen unbekannten Wert braucht es einen Default-Fall (sonst): null zurückgeben, eine Ausnahme werfen oder ein Standardprodukt liefern. Steht in der Aufgabe „Der Default-Fall soll nicht berücksichtigt werden“, kannst Du ihn weglassen.

Die aufrufende Methode reicht den Parameter einfach durch: bericht := erzeugeBericht(art).

Im Struktogramm (DIN 66261) gibt es für die Mehrfachauswahl ein eigenes Symbol (Fallauswahl mit einer Spalte je Fall und einer Spalte „sonst“). Ebenso richtig ist eine Kette verschachtelter Verzweigungen – ein Beispiel findest Du in den Übungsaufgaben.

Statische Fabrikmethode

Nicht jede Methode, die „Fabrikmethode“ heißt, ist das GoF-Muster. Sehr verbreitet ist die statische Fabrikmethode (static factory method): eine Klassenmethode (static), die anstelle eines Konstruktors ein Objekt erzeugt und zurückgibt. Es gibt dabei keine Erzeuger-Hierarchie; die Entscheidung trifft eine einzige Methode, meist mit einer Mehrfachauswahl.

Typischer Einsatz: Eine Klasse mit einem Typattribut (art: String) und Fallunterscheidungen in mehreren Methoden wird polymorph umgebaut. Die Oberklasse wird abstrakt, das Typattribut entfällt, jede Art wird eine Unterklasse mit überschriebenen Methoden. Die eine verbleibende Fallunterscheidung – welches Objekt erzeugt wird – wandert in eine statische Fabrikmethode der Oberklasse.

Im Klassendiagramm wird die statische Methode unterstrichen (PlantUML: {static}). Ihre Bestandteile:

• Eigenschaft static: Die Methode wird über den Klassennamen aufgerufen (Fahrkarte.erzeuge("Tag", 2)), es braucht vorher kein Objekt – das ist ja gerade der Zweck.

• Rückgabetyp: die Oberklasse bzw. das Interface (Fahrkarte), nicht eine konkrete Unterklasse.

• Übergabeparameter: alles, was die Konstruktoren brauchen, und ggf. die Art.

• Objekterzeugung mit new und Rückgabe.

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

static Fahrkarte erzeuge(String art, int preisstufe) {
    switch (art) {
        case "Einzel":
            return new Einzelfahrt(preisstufe)
        case "Tag":
            return new Tageskarte(preisstufe)
        case "Vierer":
            return new Viererkarte(preisstufe)
        default:
            return null
    }
}

static FUNCTION erzeuge(art: String, preisstufe: integer) : Fahrkarte
    case art of
        "Einzel":
            RETURN new Einzelfahrt(preisstufe)
        "Tag":
            RETURN new Tageskarte(preisstufe)
        "Vierer":
            RETURN new Viererkarte(preisstufe)
        else
            RETURN nil
    end case
END erzeuge

statisch Funktion erzeuge(art: string, preisstufe: integer): Fahrkarte
    falls art
        "Einzel":
            Rückgabe new Einzelfahrt(preisstufe)
        "Tag":
            Rückgabe new Tageskarte(preisstufe)
        "Vierer":
            Rückgabe new Viererkarte(preisstufe)
        sonst:
            Rückgabe null
    Ende falls
Ende erzeuge

def erzeuge(art, preisstufe):  # statisch, Rückgabe: Fahrkarte
    match art:
        case "Einzel":
            return Einzelfahrt(preisstufe)
        case "Tag":
            return Tageskarte(preisstufe)
        case "Vierer":
            return Viererkarte(preisstufe)
        case _:
            return None
    # Ende match
# Ende erzeuge

In Java:

public static Fahrkarte erzeuge(String art, int preisstufe) {
    switch (art) {
        case "Einzel": return new Einzelfahrt(preisstufe);
        case "Tag":    return new Tageskarte(preisstufe);
        case "Vierer": return new Viererkarte(preisstufe);
        default:       throw new IllegalArgumentException("Unbekannte Fahrkartenart: " + art);
    }
}

Damit niemand die Fabrik umgeht, werden die Konstruktoren der Unterklassen oft paketsichtbar (~) oder protected gemacht; der Konstruktor der abstrakten Oberklasse ist ohnehin nur für Unterklassen nutzbar.

Eine statische Fabrikmethode muss nicht auswählen. Sie kann auch einfach den Konstruktor ersetzen – etwa, damit der Client nicht wissen muss, dass er einen Stellvertreter bekommt. Im Galerie-Beispiel zum Proxy sieht das so aus:

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

static Bild erzeugeBild(String titel, String pfad) {
    return new BildProxy(titel, pfad)
}

static FUNCTION erzeugeBild(titel: String, pfad: String) : Bild
    RETURN new BildProxy(titel, pfad)
END erzeugeBild

statisch Funktion erzeugeBild(titel: string, pfad: string): Bild
    Rückgabe new BildProxy(titel, pfad)
Ende erzeugeBild

def erzeugeBild(titel, pfad):  # statisch, Rückgabe: Bild
    return BildProxy(titel, pfad)
# Ende erzeugeBild

Solche Methoden heißen oft getInstance(...), of(...), valueOf(...) oder erzeuge...(...).

Bekannte Beispiele aus der Java-Klassenbibliothek sind Integer.valueOf(…), List.of(…) und LocalDate.of(…).

Abgrenzung: Fabrikmethode und ihre Verwandten

Häufig werden die Muster kombiniert: Die konkreten Fabriken einer Abstrakten Fabrik sind oft Singletons, und ihre erzeugeX()-Methoden sind Fabrikmethoden.

Vor- und Nachteile

Vorteile:

• Lose Kopplung: Der Code, der Produkte benutzt, kennt nur den abstrakten Typ. Konkrete Klassen tauchen nur in den Fabrikmethoden auf.

• Erweiterbarkeit: Neue Produktvarianten erfordern neue Klassen, aber keine Änderung am vorhandenen, getesteten Code (Offen-geschlossen-Prinzip).

• Eine Verantwortung je Klasse: Die Erzeugung steht an einer Stelle; Fallunterscheidungen nach dem Typ sind gebündelt statt über das Programm verstreut.

• Testbarkeit: Für Tests kann ein Test-Erzeuger ein Ersatzprodukt (mock) liefern.

Nachteile:

• Mehr Klassen: Zu jedem neuen Produkt gehört oft ein neuer Erzeuger. Bei wenigen, stabilen Varianten ist das Überdimensionierung.

• Zusätzliche Indirektion: Wer den Code liest, sieht nicht sofort, welches Objekt entsteht.

• Gemeinsamer Obertyp nötig: Produkte, die nicht in eine gemeinsame Hierarchie passen, lassen sich nicht über eine gemeinsame Fabrikmethode erzeugen.

Typische Fehler

• Rückgabetyp zu konkret: Steht im Erzeuger #erzeugeBericht(): PdfBericht, kann CsvExport nichts anderes liefern. Der Rückgabetyp ist immer der Obertyp.

• new auf den abstrakten Typ: Rückgabe new Bericht() ist falsch – von abstrakten Klassen und Interfaces gibt es keine Objekte.

• Produkt ohne Obertyp: Eine neue Produktklasse wird ergänzt, aber die Generalisierung (bzw. Realisierung) zum Produkt fehlt.

• Fallunterscheidung im Erzeuger: wenn this ist PdfExport dann bericht := new PdfBericht() in der Oberklasse hebelt das Muster aus. Die Entscheidung gehört in die überschreibende Methode.

• Neuer Erzeuger vergessen: Beim Ergänzen eines Diagramms wird nur das Produkt eingetragen, aber nicht der konkrete Erzeuger mit der überschriebenen Fabrikmethode (oder umgekehrt).

• Statische Fabrikmethode: static (Unterstreichung) fehlt, der Rückgabetyp fehlt, die Parameter werden nicht an den Konstruktor weitergereicht, oder Rückgabe fehlt.

• Mehrfachauswahl: Selektor fehlt, oder in einem Fall wird das Objekt zwar erzeugt, aber nicht zurückgegeben.

Die Fabrikmethode in Aufgaben

Typische Aufgabenformen und worauf es dabei ankommt:

1. Erläutern (oft anhand eines englischen Textes): Nenne einen Aspekt und erkläre ihn am Beispiel: Erzeugungsschnittstelle in der Oberklasse – Konstruktoraufruf in eine Methode verlagert – Unterklassen überschreiben und bestimmen den Typ. Bei „Einschränkung“ ist der gemeinsame Obertyp der Produkte gemeint.

2. Klassendiagramm ergänzen: Für eine neue Variante beide Klassen eintragen: konkretes Produkt (mit Konstruktor und überschriebenen Methoden, Generalisierung zum Produkt) und konkreten Erzeuger (mit überschriebener Fabrikmethode, Generalisierung zum Erzeuger).

3. Fabrikmethode implementieren: Rückgabe new KonkretesProdukt(...), bei Parametern mit Mehrfachauswahl über den Parameter.

4. Aufrufende Methode implementieren: Fabrikmethode aufrufen, Ergebnis in einer Variablen vom Obertyp speichern, weitere Methoden am Produkt aufrufen, Ergebnis zurückgeben.

5. Statische Fabrikmethode: static, Rückgabetyp, Parameter, new, Rückgabe – zu einer vollständigen Lösung gehört jeder dieser Bestandteile.

Vokabeln für englische Fachtexte: creational pattern (Erzeugungsmuster), factory method (Fabrikmethode), to instantiate (ein Objekt erzeugen), superclass/base class (Ober-/Basisklasse), subclass (Unterklasse), to override (überschreiben), return type (Rückgabetyp), to alter (verändern), constructor call (Konstruktoraufruf), limitation (Einschränkung), common interface (gemeinsame Schnittstelle), to defer (aufschieben, übertragen).

Zum Üben findest Du zwei umfangreiche Aufgaben in den Übungsaufgaben zur Fabrikmethode.

Leitfragen

1. Welches Problem löst die Fabrikmethode, und zu welcher Kategorie von Entwurfsmustern gehört sie? Antwort

Die Fabrikmethode verhindert, dass Code mit new fest an konkrete Klassen gebunden ist und bei jeder neuen Variante geändert werden muss: Eine Klasse legt fest, dass ein Objekt erzeugt wird, ihre Unterklassen entscheiden, welches. Sie gehört zu den Erzeugungsmustern (creational patterns), siehe Abschnitt „Das Problem: new an der falschen Stelle“ und Abschnitt „Die Idee der Fabrikmethode“.

2. Welche drei Kernaspekte der Fabrikmethode kannst Du an einem Beispiel erläutern? Antwort

Erstens deklariert die Oberklasse (Erzeuger) eine Schnittstelle zur Erzeugung, die Fabrikmethode. Zweitens wird der Konstruktoraufruf in diese Methode verlagert, der nutzende Code kennt nur noch den abstrakten Typ. Drittens überschreiben die Unterklassen die Fabrikmethode und bestimmen so den Typ des erzeugten Objekts, etwa PdfExport und CsvExport im Berichtsbeispiel, siehe Abschnitt „Die Idee der Fabrikmethode“ und Abschnitt „Ein Beispiel: Berichte exportieren“.

3. Welche Rollen gibt es im Muster, und wie hängen die beiden Vererbungshierarchien im Klassendiagramm zusammen? Antwort

Die Rollen sind Produkt (gemeinsamer Obertyp), konkretes Produkt, Erzeuger (deklariert die Fabrikmethode mit Rückgabetyp Produkt) und konkreter Erzeuger (überschreibt sie). Es gibt zwei parallele Hierarchien: Jeder konkrete Erzeuger erbt vom Erzeuger und erzeugt ein konkretes Produkt, das vom Produkt erbt bzw. es realisiert; die Erzeugung wird als Abhängigkeit mit «Create» dargestellt, siehe Abschnitt „Rollen und Klassendiagramm“.

4. Welche Einschränkung gilt für die Klassenstruktur, und warum muss der Rückgabetyp der Fabrikmethode der gemeinsame Obertyp sein? Antwort

Alle Produkte müssen eine gemeinsame Basisklasse haben oder ein gemeinsames Interface implementieren, und die Fabrikmethode im Erzeuger muss diesen Obertyp zurückgeben. Nur so können die überschreibenden Methoden unterschiedliche Produkte liefern und der aufrufende Code alle Produkte polymorph einheitlich behandeln, siehe Abschnitt „Die Einschränkung: Alle Produkte brauchen einen gemeinsamen Obertyp“.

5. Welche Klassen musst Du ergänzen, wenn eine neue Produktvariante hinzukommt? Antwort

Du ergänzt genau zwei Klassen: das neue konkrete Produkt (erbt vom Produkt bzw. realisiert es) und den neuen konkreten Erzeuger, der die Fabrikmethode überschreibt und das neue Produkt zurückgibt. Vorhandene Klassen bleiben unverändert (Offen-geschlossen-Prinzip), siehe Abschnitt „Ein Beispiel: Berichte exportieren“ und Abschnitt „Die Fabrikmethode in Aufgaben“.

6. Wie implementierst Du eine Fabrikmethode mit Übergabeparameter und Mehrfachauswahl, und wie eine Methode, die sie aufruft? Antwort

Die Fabrikmethode erhält einen Parameter, der in einer Mehrfachauswahl als Selektor dient; je Fall erzeugst Du mit new das passende konkrete Produkt und gibst es zurück, der Rückgabetyp bleibt der Obertyp, und für unbekannte Werte gibt es einen Default-Fall. Die aufrufende Methode ruft die Fabrikmethode auf, speichert das Ergebnis in einer Variablen vom Obertyp, arbeitet damit weiter und gibt es zurück, siehe Abschnitt „Parametrisierte Fabrikmethode“ und Abschnitt „Ein Beispiel: Berichte exportieren“.

7. Woran erkennst Du eine statische Fabrikmethode, und aus welchen Bestandteilen besteht sie? Antwort

Eine statische Fabrikmethode ist eine Klassenmethode, die im Klassendiagramm unterstrichen ist und anstelle eines Konstruktors ein Objekt liefert, ohne Erzeuger-Hierarchie. Ihre Bestandteile sind die Eigenschaft static, der Rückgabetyp (Oberklasse bzw. Interface), die Übergabeparameter sowie die Objekterzeugung mit new und die Rückgabe, siehe Abschnitt „Statische Fabrikmethode“.

8. Worin unterscheiden sich Fabrikmethode, statische Fabrikmethode, Abstrakte Fabrik und Singleton? Antwort

Bei der Fabrikmethode entscheidet die Unterklasse des Erzeugers per Vererbung, bei der statischen Fabrikmethode eine einzelne Klassenmethode (oft per Mehrfachauswahl). Die Abstrakte Fabrik erzeugt über ein Fabrikobjekt eine ganze Familie zusammenpassender Produkte, und das Singleton stellt sicher, dass es von einer Klasse genau ein Objekt gibt, siehe Abschnitt „Abgrenzung: Fabrikmethode und ihre Verwandten“.

Links und weitere Informationen

• Übungsaufgaben zur Fabrikmethode

• Entwurfsmuster: Strategie, Zustand, Proxy und Dekorierer

• Polymorphie

• Abstrakte Klassen und Interfaces

• Übersicht der Design-Pattern-Artikel auf oer-informatik.de

• als Nachschlagewerk: Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Entwurfsmuster – Elemente wiederverwendbarer objektorientierter Software. mitp (deutsche Ausgabe des GoF-Buchs)

• zum Stöbern: Refactoring.Guru: Fabrikmethode (Musterbeschreibung mit Beispielen in vielen Sprachen)

• für Fortgeschrittene: Joshua Bloch: Effective Java, Kapitel „Consider static factory methods instead of constructors“ (Vor- und Nachteile statischer Fabrikmethoden)

Hinweis zur Nachnutzung als Open Educational Resource (OER)

Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Entwurfsmuster Fabrikmethode (Factory Method)” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/entwurfsmuster-fabrikmethode veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/design-pattern/entwurfsmuster. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 28.10.2026.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]