Entwurfsmuster in der Praxis. Wann sie helfen und wann sie Code erschweren

Ein Entwurfsmuster beweist keine Seniorität. Es benennt eine Lösung, die sich bei einer bestimmten Problemart wiederholt bewährt hat. Fehlt dieses Problem, erzeugt das Muster zusätzliche Dateien, Schnittstellen und Begriffe, ohne ein reales Risiko zu senken.

Bei Unternehmenssoftware beginnt die Entscheidung deshalb mit der erwarteten Änderung. Wer ändert welche Regel und welcher Teil soll dabei stabil bleiben? Erst danach lässt sich beurteilen, ob Strategy, Adapter, Factory oder eine direkte Funktion passt.

1. 01

   Eine stabile Regel

   Behalten Sie eine direkte Funktion.

2. 02

   Wechselnder Algorithmus

   Prüfen Sie Strategy.

3. 03

   Fremde Schnittstelle

   Isolieren Sie sie mit einem Adapter.

4. 04

   Mehrere Erzeugungswege

   Eine Factory kann den Aufbau kapseln.

Einfacher Code ist kein primitiver Code

Nehmen wir die Berechnung von Versandkosten. Die erste Version kennt Abholung und einen Paketdienst. Zwei Bedingungen in einer Funktion sind hier leichter zu verstehen als eine Hierarchie aus Klassen. Eingabe, Regel und Ergebnis stehen beieinander.

Der Druck entsteht, wenn sich Regeln unabhängig entwickeln. Ein Anbieter berechnet nach Gewicht, ein anderer nach Region. Vertragskunden haben eigene Konditionen. Die Funktion erhält mehrere voneinander unabhängige Gründe für Änderungen. Eine Anpassung für einen Anbieter kann nun andere Wege beschädigen.

Guter Entwurf reagiert nicht auf die Zahl der Zeilen. Entscheidend ist die Zahl unabhängiger Änderungsgründe. Fünfzig stabile Zeilen können einfacher sein als zehn Zeilen, die jede Woche aus verschiedenen geschäftlichen Gründen verändert werden.

Strategy trennt eine veränderliche Regel

Strategy passt, wenn die Aufgabe gleich bleibt und der Algorithmus austauschbar ist. Ein Versandpreis wird weiterhin berechnet. Nur die Berechnung unterscheidet sich je nach Anbieter oder Vertrag.

type DeliveryQuote = (order: Order) => Money;

const quoteDelivery = (order: Order, quote: DeliveryQuote): Money =>
  quote(order);

Eine Strategy braucht keine Klasse. In TypeScript genügen häufig ein Typ und mehrere reine Funktionen. Die Bestellung kennt die Preistabelle nicht. Der Rechner muss nicht wissen, woher die Bestellung stammt. Eine neue Regel lässt sich ergänzen, ohne bestehende Algorithmen zu ändern.

Das Muster ist ungeeignet, wenn nur eine stabile Berechnung existiert oder alle Varianten viel veränderlichen Zustand teilen. Kleine Strategy-Dateien verschieben dann Bedingungen, statt Änderungen zu isolieren. Die tatsächliche Grenze muss zuerst sichtbar werden.

Adapter schützt die Domäne vor fremden Modellen

ERP, Zahlungsdienst oder Paketdienst bringen eigene Namen, Datentypen und Fehlerzustände mit. Gelangen sie direkt in den Kern, spricht die Domäne bald die Sprache eines Anbieters. Eine neue API-Version berührt dann Bestellungen, Rechnungen und Oberfläche zugleich.

Ein Adapter übersetzt das fremde Modell in einen kleinen Vertrag, den das eigene System besitzt. Die Domäne kann reserveStock verlangen, obwohl ein ERP Lagerbewegungen und ein anderes Artikelreservierungen anbietet. Der Unterschied bleibt an der Integrationsgrenze.

Diese Grenze vereinfacht Tests. Ein Domänentest braucht weder Netzwerk noch Testkonto des Anbieters. Er prüft das Verhalten gegen den eigenen Vertrag. Ein separater Integrationstest beweist die richtige Übersetzung von Anfrage, Antwort und Fehlern.

Ein Adapter ist kein Schrank für beliebige Unordnung. Benennt er nur jedes Feld um und bleibt die externe Schnittstelle stabil, ist sein Nutzen gering. Sein Wert wächst mit dem fachlichen Abstand zwischen fremdem Modell und eigener Domäne.

Factory verbirgt den Aufbau

Factory hilft beim Erzeugen eines Objekts oder Arbeitsablaufs, wenn der Aufbau vom Eingangstyp abhängt. Ein PDF-Rechnungsprozessor braucht vielleicht OCR, Rechnungsprüfung und Buchhaltungszuordnung. Ein Vertrag verwendet einen anderen Extraktor und andere Prüfungen.

Der Aufrufer muss die Reihenfolge aller Abhängigkeiten nicht kennen. Er fordert einen Prozessor für einen Dokumenttyp an. Die Factory baut ihn und liefert ihn über einen gemeinsamen Vertrag zurück.

Geschäftliche Entscheidungen dürfen nicht in einer großen Factory mit vielen Verzweigungen verschwinden. Die Auswahl technischer Bausteine gehört zum Aufbau. Die Entscheidung, ob eine Rechnung automatisch gebucht werden darf, ist eine Domänenregel. Sie muss sichtbar und separat testbar bleiben.

1. 01

   Vorher

   Ein Dienst kennt Preise, Anbieter und Dokumentformate.

2. 02

   Nach der Trennung

   Die Domäne ruft eine kleine Schnittstelle auf, Änderungsdetails bleiben hinter der Grenze.

Ein Muster muss die nächste Änderung begrenzen

Im Review helfen drei Fragen. Können wir eine konkrete erwartete Änderung nennen? Bleibt diese Änderung nach Einführung des Musters hinter einer Grenze? Ist das Ergebnis für jemanden verständlicher, der die Vorgeschichte nicht kennt?

Bei einem Nein kam die Abstraktion wahrscheinlich zu früh. Code muss nicht jede denkbare Zukunft abdecken. Er soll jene Änderungen aufnehmen, die aus Produkt, Verträgen und Betrieb tatsächlich folgen.

Muster können zusammenarbeiten. Ein Adapter gibt der Domäne eine eigene Schnittstelle. Strategy hält die variable Regel. Factory setzt die benötigten Abhängigkeiten zusammen. Das ist nur sinnvoll, wenn jeder Teil eine andere Grenze schützt. Beschreiben drei Namen dieselbe Bedingung, ist der Entwurf zu groß.

Was Auftraggeber fragen sollten

Eine Geschäftsleitung muss kein Klassendiagramm prüfen. Sie sollte erfahren, ob eine neue Zahlungsart oder ein ERP-Wechsel das ganze System betrifft. Eine technische Leitung braucht die Stelle der Regel, ihren Vertrag und den Test, der das Verhalten schützt.

Bei individueller Softwareentwicklung verbinden wir technische Grenzen mit erwarteten geschäftlichen Änderungen. Der nächste Beitrag überträgt dieses Denken auf die Wahl zwischen modularem Monolithen und Microservices. Zum Einfluss von KI auf Entwicklungsarbeit passt außerdem unser Text über menschliche Kontrolle bei KI-gestützter Entwicklung.

Das beste Muster fällt im Alltag kaum auf. Eine neue Änderung hat einen offensichtlichen Ort. Der Test besitzt einen klaren Zweck, und der übrige Code muss die Änderung nicht kennen. Vor der Einführung lohnt sich deshalb eine letzte Probe. Würde eine direkte Funktion denselben Änderungsraum verständlicher halten, bleibt sie die bessere Lösung. Abstraktion verdient ihren Platz durch weniger Änderungsrisiko, nicht durch ihren bekannten Namen.

Die Entscheidung sollte kurz festgehalten werden. Problem, erwartete Änderung und geschützte Grenze genügen. So versteht eine spätere Entwicklerin nicht nur den Aufbau, sondern auch den Grund. Verschwindet die ursprüngliche Annahme, darf das Muster wieder entfernt werden. Ein Entwurf ist kein Museum. Er soll die gegenwärtige Arbeit erleichtern und mit dem Produkt kleiner oder größer werden können.