DRY (Don't Repeat Yourself) ist das Prinzip aus Andy Hunts und Dave Thomas' The Pragmatic Programmer (1999), nach dem jedes Stück Wissen in einem System eine einzige, eindeutige, maßgebliche Darstellung haben muss. Es zielt auf dupliziertes Wissen und duplizierte Absicht, etwa eine Geschäftsregel oder ein Schema, nicht auf Code, der nur ähnlich aussieht. Andere Artefakte werden aus einer Single Source of Truth abgeleitet, und abstrahiert wird erst nach der Rule of Three, denn die falsche Abstraktion kostet mehr als Duplizierung.

DRY (Don’t Repeat Yourself)

Details
Vollständiger Name

Don’t Repeat Yourself

Auch bekannt als

DRY-Prinzip; Gegenstück: WET („Write Everything Twice" / „We Enjoy Typing")

Kernkonzepte:

Das Prinzip

„Every piece of knowledge must have a single, unambiguous, authoritative representation within a system." Ein Fakt — eine Geschäftsregel, eine Konstante, ein Schema — lebt an genau einer Stelle

Wissen, nicht Code

DRY zielt auf dupliziertes Wissen/Intention, nicht auf zufällige textuelle Ähnlichkeit. Zwei ähnlich aussehende Fragmente, die sich aus unterschiedlichen Gründen ändern, sind keine DRY-Verletzung; sie zusammenzulegen koppelt unverwandte Belange

Single Source of Truth

Ableiten statt wiederholen — Doku/Config/Clients aus einer maßgeblichen Definition generieren, damit eine Änderung sich fortpflanzt statt kopiert zu werden

Rule of Three

Eine gemeinsame Abstraktion erst beim dritten Auftreten extrahieren, nicht beim ersten (Martin Fowler). Verfrühtes Entdoppeln rät die Abstraktion, bevor das Muster klar ist

Warnung vor der falschen Abstraktion

„Duplication is far cheaper than the wrong abstraction" (Sandi Metz). Eine schlechte gemeinsame Abstraktion koppelt die Aufrufer und ist schwerer aufzulösen als die entfernte Duplizierung — lieber duplizieren, bis die richtige Naht offensichtlich ist

Key Proponents

Andy Hunt & Dave Thomas, The Pragmatic Programmer (1999)

Verwendung:

  • Konsolidierung einer Geschäftsregel, Konstante oder eines Schemas, das an mehreren Stellen auftaucht

  • Entwurf einer Single Source of Truth (Config, Typen, API-Contracts), aus der andere Artefakte abgeleitet werden

  • Code-Review auf Wissensduplizierung, die Änderungen an vielen Stellen erzwingt

Nicht verwenden:

  • Vor der Rule of Three — beim ersten oder zweiten Auftreten nicht abstrahieren

  • Wenn zwei ähnliche Fragmente sich aus unterschiedlichen Gründen ändern — Kopplung über eine gemeinsame Abstraktion ist schlimmer als die Duplizierung

  • Als Dogma über Lesbarkeit: etwas Duplizierung schlägt eine undichte, übergeneralisierte Abstraktion

Verwandte Anker:

Kritik:

  • Sandi Metz, "The Wrong Abstraction" (2016) — übereifriges DRY erzeugt Abstraktionen, in die spätere Anforderungen nicht passen: "duplication is far cheaper than the wrong abstraction"; ihr Rat: die Duplizierung wieder einführen, bis sich die richtige Abstraktion zeigt

  • Die Autoren selbst räumen ein, dass das Prinzip breit missverstanden wird: In der 20th Anniversary Edition (2019) schreiben Thomas & Hunt, sie hätten DRY ursprünglich "schlecht erklärt" — es zielt auf Duplizierung von Wissen und Absicht; Code-Deduplizierung ist "ein winziger und ziemlich trivialer Teil" (offizieller Kapitelauszug)

  • Die Folgerung beider Kritiken: Zwei Code-Stücke, die gleich aussehen, aber unterschiedliches Fachwissen kodieren, sind keine DRY-Verletzung — sie zu verschmelzen erzeugt Kopplung, nicht Klarheit