Zum Inhalt
wannacode

Factory Method und Simple Factory

Kurz gesagt: Eine Factory hält die Entscheidung, welche Klasse erzeugt wird, an einer Stelle: Simple Factory legt die Wahl an einen Ort, und Factory Method lässt eine Unterklasse entscheiden, welches Objekt entsteht.

Problem

Drei Stellen kennen jede Lieferart

Die Bestellung sagt, wie sie zum Kunden kommt: "address" (an die Haustür), "office" (in einer Kurierfiliale) oder "locker" (in einer Packstation). Jede Art hat eine Klasse mit eigenem Preis und eigenem Etikett:

class AddressDelivery:
    price = 5.90


    def label(self, recipient):
        return f"{recipient}, an die Haustür"




class OfficeDelivery:
    price = 3.90


    def label(self, recipient):
        return f"{recipient}, in einer Kurierfiliale"




class LockerDelivery:
    price = 2.90


    def label(self, recipient):
        return f"{recipient}, in einer Packstation"

Drei Teile des Shops brauchen die Lieferung: die Kasse, die Preisvorschau und der Etikettendrucker. Jeder entscheidet selbst, welche Klasse er erzeugt:

def checkout(kind, items):
    if kind == "address":
        delivery = AddressDelivery()
    elif kind == "office":
        delivery = OfficeDelivery()
    elif kind == "locker":
        delivery = LockerDelivery()
    else:
        raise ValueError(kind)
    return items + delivery.price




def preview_price(kind):
    if kind == "address":
        delivery = AddressDelivery()
    elif kind == "office":
        delivery = OfficeDelivery()
    elif kind == "locker":
        delivery = LockerDelivery()
    else:
        raise ValueError(kind)
    return delivery.price




def print_label(kind, recipient):
    if kind == "office":
        delivery = OfficeDelivery()
    else:
        delivery = AddressDelivery()
    return delivery.label(recipient)
print(f"Bestellung: {checkout("locker", 40):.2f} €")
print(f"Vorschau: Lieferung {preview_price("locker"):.2f} €")
print("Etikett: " + print_label("locker", "Maria"))
Ausgabe
Bestellung: 42.90 €
Vorschau: Lieferung 2.90 €
Etikett: Maria, an die Haustür

Letzten Monat kamen die Packstationen dazu. Jemand hat "locker" in der Kasse und in der Vorschau ergänzt. Der Etikettendrucker wurde davor geschrieben und hat für die Adresse ein else. Maria hat die Lieferung an eine Packstation bezahlt, und der Kurier ist zu ihrer Adresse gefahren.

Eine neue Art sind drei Änderungen, und eine wird vergessen. Die Wahl „welche Klasse für welche Art“ ist kopiert, und die Kopien wissen nichts voneinander.

Die Idee

Simple Factory: new lebt an einer Stelle

Die Wahl „welche Klasse für welche Art“ ist eine einzige Entscheidung, also lebt sie an einer Stelle: in einer Factory. Sie bekommt die Art und gibt ein neues Objekt zurück. Der Aufrufer ruft die Klasse nicht auf und kennt die Klasse nicht: Er bekommt ein Objekt mit price und label.

Die Rollen:

  • das Produkt: die gemeinsame Form, price und label(recipient), die jede Klasse hat;
  • die konkreten Produkte: AddressDelivery, OfficeDelivery, LockerDelivery;
  • die Factory: create_delivery(kind), die einzige Stelle, die weiß, welche Klasse zu welcher Art gehört;
  • die Clients: die Kasse, die Vorschau, das Etikett. Sie fragen nur.

Das heißt Simple Factory. Es stammt nicht aus dem Buch der Gang of Four, ist aber die häufigste Form. Factory Method aus dem Buch ist etwas anderes und kommt weiter hinten in der Lektion.

Eine Regel: Eine unbekannte Art ist ein Fehler, kein stiller Standardwert. Eine Factory, die die Art nicht kennt, wirft eine Exception mit einer klaren Meldung. Sonst verschwindet der Fehler nicht, er fährt mit dem Kurier zur falschen Adresse.

In Python ist die Factory eine Tabelle Art → Klasse. Eine Klasse erzeugt Objekte von selbst: AddressDelivery() ist ein neues Objekt, also hält die Tabelle die Klassen selbst, und DELIVERIES[kind]() ruft die richtige auf.

Die Tabelle „Name → Strategie“ aus der Lektion zu Strategy ist dasselbe: eine Factory, die dir zu einem Stück Text ein Objekt gibt.

Sieh es dir an

Eine Factory für die drei Stellen

DELIVERIES = {
    "address": AddressDelivery,
    "office": OfficeDelivery,
    "locker": LockerDelivery,
}




def create_delivery(kind):
    if kind not in DELIVERIES:
        raise ValueError(f"Unbekannte Lieferart: {kind}")
    return DELIVERIES[kind]()

Die Kasse, die Vorschau und das Etikett wählen nicht mehr, sie fragen:

def checkout(kind, items):
    return items + create_delivery(kind).price




def preview_price(kind):
    return create_delivery(kind).price




def print_label(kind, recipient):
    return create_delivery(kind).label(recipient)
print(f"Bestellung: {checkout("locker", 40):.2f} €")
print(f"Vorschau: Lieferung {preview_price("locker"):.2f} €")
print("Etikett: " + print_label("locker", "Maria"))
Ausgabe
Bestellung: 42.90 €
Vorschau: Lieferung 2.90 €
Etikett: Maria, in einer Packstation

Das Etikett ist für eine Packstation. Die Wahl steht an einer Stelle, also kann sie nicht an der Kasse stimmen und auf dem Etikett falsch sein.

Genauer, für Neugierige

Warum nicht DELIVERIES.get(kind)()? Fehlt die Art, gibt get None zurück, und None() ergibt TypeError: 'NoneType' object is not callable. Der Fehler sagt nicht, welche Art unbekannt ist. Die Prüfung if kind not in DELIVERIES mit einer klaren Meldung kostet zwei Zeilen.

Sieh es dir an

Eine neue Art: eine Klasse und eine Zeile

Der Shop führt die Abholung im Geschäft ein: Art "pickup", kostenlos. Neu ist eine Klasse:

class PickupDelivery:
    price = 0.00


    def label(self, recipient):
        return f"{recipient}, im Geschäft"

und eine Zeile in der Factory, hier hervorgehoben:

DELIVERIES = {
    "address": AddressDelivery,
    "office": OfficeDelivery,
    "locker": LockerDelivery,
    "pickup": PickupDelivery,
}




def create_delivery(kind):
    if kind not in DELIVERIES:
        raise ValueError(f"Unbekannte Lieferart: {kind}")
    return DELIVERIES[kind]()
home = create_delivery("address")
print(f"{home.label('Maria')}: {home.price:.2f} €")


locker = create_delivery("locker")
print(f"{locker.label('Maria')}: {locker.price:.2f} €")


pickup = create_delivery("pickup")
print(f"{pickup.label('Maria')}: {pickup.price:.2f} €")
Ausgabe
Maria, an die Haustür: 5.90 €
Maria, in einer Packstation: 2.90 €
Maria, im Geschäft: 0.00 €

home = create_delivery("address")
print(f"{home.label('Maria')}: {home.price:.2f} €")


locker = create_delivery("locker")
print(f"{locker.label('Maria')}: {locker.price:.2f} €")


pickup = create_delivery("pickup")
print(f"{pickup.label('Maria')}: {pickup.price:.2f} €")
Schritt für Schritt, in Worten
  1. create_delivery("address") bekommt nur den Text aus der Bestellung. Die Factory sucht die passende Form dafür.
  2. Aus der Form kommt ein neues AddressDelivery. Der Aufrufer fragt nicht, welche Klasse es ist: Er benutzt nur price und label().
  3. Dieselbe Factory, ein anderer Text: „locker“ geht an den anderen Formen vorbei und hält bei LockerDelivery.
  4. Das Etikett sagt jetzt Packstation: Die Klasse wird an einer Stelle gewählt, und die Kasse, die Vorschau und das Etikett fragen alle diese Stelle.
  5. Eine neue Art: die Klasse PickupDelivery und eine Zeile mehr in der Factory. Die Zeilen, die create_delivery aufrufen, ändern sich nicht.
  6. „pickup“ läuft durch wie jede andere Art. Die neue Art wurde an einer Stelle hinzugefügt.

Die Kasse, die Vorschau und das Etikett werden nicht angefasst. Sie erfahren von der neuen Art, wenn eine Bestellung sie verlangt.

Sieh es dir an

Unbekannte Art

Die Art kommt von außen: aus einem Formular, von der Seite eines Partners, aus einer alten Datei. Früher oder später taucht eine Art auf, die es nicht gibt:

try:
    delivery = create_delivery("drone")
    print(delivery.label("Maria"))
except ValueError as e:
    print(e)
Ausgabe
Unbekannte Lieferart: drone

Der Fehler sagt, welche Art unbekannt ist. Er wird dort abgefangen, wo die Bestellung in den Shop kommt, und der Kunde sieht eine Meldung statt eines Pakets am falschen Ort.

Und ohne die Prüfung? DELIVERIES[kind] ergibt einen KeyError mit der Art, aber die Meldung ist für den Entwickler, nicht für die Bestellung:
def create_delivery(kind):
    return DELIVERIES[kind]()
Fehler
KeyError: 'drone'

Sieh es dir an

Factory Method: die Unterklasse entscheidet

Simple Factory wählt nach Text. Manchmal richtet sich die Wahl aber nicht nach Text, sondern danach, welches Objekt fragt.

Der Verkaufsbericht wird als CSV (für die Buchhaltung) und als HTML-Tabelle (in einer E-Mail) verschickt. Beide tun dasselbe: Jedes Produkt ist eine Zeile, und am Ende steht eine Zeile „Gesamt“. Nur die Datei, in die die Zeilen geschrieben werden, ist anders:

class CsvFile:
    def __init__(self):
        self.lines = ["Produkt;Summe"]


    def add(self, product, total):
        self.lines.append(f"{product};{total:.2f}")


    def text(self):
        return "\n".join(self.lines)




class HtmlFile:
    def __init__(self):
        self.rows = []


    def add(self, product, total):
        self.rows.append(f"<tr><td>{product}</td><td>{total:.2f}</td></tr>")


    def text(self):
        return "<table>\n" + "\n".join(self.rows) + "\n</table>"
Der gemeinsame Algorithmus steht in der Basisklasse. Welche Datei erzeugt wird, sagt das Klassenattribut file_class: Eine Klasse ist ein Wert, und eine Unterklasse setzt eine andere ein. Frameworks wie Django machen es auch so.
class ReportExporter:
    file_class = CsvFile


    def export(self, sales):
        file = self.file_class()
        overall = 0
        for product, total in sales:
            file.add(product, total)
            overall += total
        file.add("Gesamt", overall)
        return file.text()




class HtmlExporter(ReportExporter):
    file_class = HtmlFile
sales = [("Kaffee", 12.50), ("Tee", 8.00)]
print(ReportExporter().export(sales))
print(HtmlExporter().export(sales))
Ausgabe
Produkt;Summe
Kaffee;12.50
Tee;8.00
Gesamt;20.50
<table>
<tr><td>Kaffee</td><td>12.50</td></tr>
<tr><td>Tee</td><td>8.00</td></tr>
<tr><td>Gesamt</td><td>20.50</td></tr>
</table>

Das ist Factory Method: Die Basisklasse ruft eine Methode auf, die das Objekt erzeugt (self.file_class()), und die Unterklasse entscheidet, welche Klasse genau.

Warum nicht eine fertige Datei hineingeben? Die Datei sammelt Zeilen. Jeder export muss mit einer leeren Datei beginnen, also hält der Bericht keine Datei, er weiß, wie man eine neue erzeugt.

Wann genügt Simple Factory? Factory Method lohnt sich, wenn es um die Erzeugung herum einen gemeinsamen Algorithmus gibt, den die Unterklassen nicht wiederholen sollen (hier: die Zeilen und die Summe). Willst du nur ein Objekt nach Art, ohne Algorithmus drumherum, ist Simple Factory klarer. Und eine Unterklasse, die nur existiert, um ein neues Objekt zurückzugeben, ist Zeremonie. Dann gib die Klasse selbst mit: export(sales, HtmlFile).

Probier es aus

Was kommt heraus?

Die Arten kommen aus einem Formular auf der Seite. Was gibt das Programm aus?

for kind in ["office", "Locker", "locker"]:
    try:
        print(create_delivery(kind).label("Maria"))
    except ValueError as e:
        print(e)
Antwort

Probier es aus

Finde den Fehler

Ein anderer Entwickler hat die Factory so geschrieben:

DELIVERIES = {
    "office": OfficeDelivery,
    "locker": LockerDelivery,
}




def create_delivery(kind):
    return DELIVERIES.get(kind, AddressDelivery)()

Die Bestellung kommt von der Seite eines Partners, die die Art mit großem Anfangsbuchstaben sendet:

delivery = create_delivery("Locker")
print("Etikett: " + delivery.label("Maria"))
print(f"Lieferung: {delivery.price:.2f} €")
Ausgabe
Etikett: Maria, an die Haustür
Lieferung: 5.90 €

Maria hat eine Packstation gewählt. Sie hat 5,90 € statt 2,90 € für die Lieferung bezahlt, und das Paket ging an ihre Adresse. In welcher Zeile steckt der Fehler?

Wähle die Zeile mit dem Fehler.

Die Idee

Wann du es nicht brauchst

Eine Factory ist ein Sprung mehr beim Lesen: Um zu sehen, welche Klasse erzeugt wird, gehst du woandershin. Es lohnt sich nicht, wenn:

  • diese Stelle immer dieselbe Klasse braucht. OfficeDelivery() dort, wo die Lieferung immer an eine Filiale geht, ist klarer als eine Factory;
  • die Art beim Schreiben des Codes bekannt ist und nicht als Daten hereinkommt (aus einer Bestellung, einer Datei, einem Formular);
  • du eine Klasse DeliveryFactory mit nur einer statischen Methode schreibst. Eine Tabelle und eine Funktion genügen;
  • eine Factory Method eine Unterklasse „für die Zukunft“ hat.

Es lohnt sich, wenn die Art als Daten hereinkommt und die Wahl der Klasse sonst an mehreren Stellen kopiert würde. Oder wenn es um die Erzeugung herum einen gemeinsamen Algorithmus gibt und nur der Schritt „welches Objekt“ anders ist.

Übung

Expresslieferung

Löse das in deinem Editor.

Expresslieferung. Der Shop führt die Expresslieferung an die Haustür ein: Art "express", 9,90 €, Etikett „…, Express an die Haustür“. Füge eine Klasse ExpressDelivery hinzu und mach sie über die Factory verfügbar. Die Kasse, die Vorschau und das Etikett werden nicht angefasst. Erzeuge eine Expresslieferung für Maria und gib sie aus wie in der Karte „Eine neue Art“:

Ausgabe
Maria, Express an die Haustür: 9.90 €

Weitere Aufgaben

  • Großbuchstaben und Leerzeichen. Das Formular sendet "Locker" und " locker ". Lass die Factory sie akzeptieren und ändere nur die Factory. Unbekannte Arten müssen weiter einen Fehler ergeben.
  • Ein JSON-Bericht. Füge dem Bericht aus der Karte „Factory Method“ ein JSON-Format hinzu: [{"product": "Kaffee", "total": 12.50}, …]. Welche Klassen schreibst du, und welche fasst du nicht an?
  • Preis nach Gewicht. Packstationen nehmen Pakete bis 20 kg, und über 5 kg kostet die Lieferung an die Haustür mehr. Wohin gehört das Gewicht: in die Factory oder in die Preismethode? Überlege, warum.

Test

Teste dich

1. Der Shop führt Drohnenlieferung ein, Art "drone". Was schreibst du mit Simple Factory?
2. Die Factory bekommt eine Art, die sie nicht kennt. Was soll sie tun?
3. Wann ist Factory Method besser als Simple Factory?
4. Um Speicher zu sparen, hält die Tabelle für jede Art ein fertiges Objekt, und die Factory gibt es zurück. Das Objekt hält den Empfänger in einem Feld. Was passiert bei zwei Packstation-Bestellungen hintereinander?
5. Wann brauchst du keine Factory?

Erstellt von Ivo Gergov im Rahmen der Kampagne von Evo Tech für zugängliche Programmierausbildung ·