DRY in der mobilen Entwicklung — was es ist, das Prinzip und warum Duplizierung schädlich ist

Was ist DRY?

DRY (Don't Repeat Yourself) ist ein Entwicklungsprinzip, das verlangt, jedes Wissenselement in einem Projekt genau einmal zu speichern. Das bedeutet, dass jede Logik, Konfiguration oder Metadaten an genau einem Ort existieren sollten.

Der Begriff wurde 1999 von Andy Hunt und Dave Thomas im Buch „The Pragmatic Programmer“ eingeführt. Die Autoren definierten DRY als „Jeder Teil des Wissens muss eine einzige, eindeutige, autoritative Darstellung innerhalb eines Systems haben.“ Das Gegenteil von DRY ist der WET-Ansatz (Write Everything Twice), bei dem Duplizierung als normal angesehen wird.

Laut einer Studie der University of California, Davis (2019) verbringen Projekte mit hohem Grad an Code-Duplizierung 42% mehr Zeit mit der Fehlerbehebung. Der Grund ist, dass Entwickler alle Kopien desselben Fragments finden und ändern müssen — und bei der manuellen Suche sind Auslassungen unvermeidlich.

Wenden Sie DRY als Code-Qualitätskriterium an. Wenn Ihnen auffällt, dass dasselbe Muster dreimal in einem Projekt vorkommt — extrahieren Sie es in eine Abstraktion, ohne auf eine vierte Wiederholung zu warten.

Unterschied zwischen DRY und dem Single-Responsibility-Prinzip

Single Responsibility Principle (SRP) aus SOLID besagt, dass eine Klasse einen einzigen Grund für Änderungen haben sollte. DRY ist breiter gefasst: Es umfasst nicht nur Klassen, sondern auch Daten, Konfiguration, Dokumentation und sogar Geschäftsregeln. SRP handelt von Verantwortungsgrenzen; DRY handelt von der Vermeidung von Kopien.

In der mobilen Entwicklung ist dieser Unterschied besonders deutlich. Wenn dieselbe Geschäftsregel (Steuerberechnung, Datumsformatierung) sowohl im Android- als auch im iOS-Teil des Projekts wiederholt wird — das ist eine DRY-Verletzung, auch wenn SRP formal innerhalb jeder Plattform eingehalten wird. Die Lösung besteht darin, die gemeinsame Logik in ein gemeinsames Modul (KMM, C++) zu extrahieren.

Laut dem Bericht Google Android Architecture Guidelines (2023) reduzieren Teams, die gemeinsame Module für Geschäftslogik verwenden, die Anzahl der Fehler bei sich ändernden Anforderungen um 37% im Vergleich zu Projekten mit plattformübergreifender Logik-Duplizierung.

Warum ist Code-Duplizierung gefährlich?

Duplizierung ist die Hauptquelle technischer Schulden in mobilen Projekten. Jede Code-Kopie erzeugt eine versteckte Abhängigkeit: Um das Verhalten zu ändern, müssen Sie alle Kopien finden und aktualisieren. Eine zu verpassen bedeutet einen Fehler.

Betrachten Sie ein klassisches Szenario: In einer Android-App wird die Datumsformatierung in drei verschiedenen Activities durchgeführt. Beim Wechsel zu einem neuen Format (z. B. ISO 8601) korrigiert der Entwickler zwei Dateien, vergisst die dritte — und der Benutzer sieht Daten im alten Format. Die App-Bewertung sinkt und die Fehlersuche dauert doppelt so lange.

Eine Studie von Google Research (2020) zeigte, dass 68% der kritischen Fehler in mobilen Anwendungen mit unsynchronisierten Änderungen in dupliziertem Code zusammenhängen. Darüber hinaus kostet die Behebung eines solchen Fehlers in der Produktion 4,5-mal mehr, als wenn der Code von Anfang an einheitlich gewesen wäre.

Verwenden Sie statische Analysatoren (Detekt, SwiftLint) mit Regeln, die Copy-Paste erkennen. Konfigurieren Sie CI so, dass Pull-Requests mit mehr als N Zeilen Duplizierung ohne Begründung keine Review bestehen.

DRY in der mobilen Entwicklung: Praxisbeispiele

Duplizierung von UI-Logik in Android

Ein typisches Anti-Pattern ist das Kopieren eines RecyclerView-Adapters mit geringfügigen Änderungen. Statt eines universellen Adapters mit Konfiguration erstellen Entwickler eine separate Klasse für jeden Bildschirm. Die Refaktorisierung durch Extraktion einer gemeinsamen Basisklasse reduziert den Code um 30–50%.

// Duplizierung: zwei separate Adapter
class UserAdapter {
    fun bind(item: User) { /* ... */ }
}
class ProductAdapter {
    fun bind(item: Product) { /* ... */ }
}

// DRY-Refaktorisierung: gemeinsame Basisklasse
abstract class BaseAdapter<T> {
    abstract fun bind(item: T)
}
class UserAdapter : BaseAdapter<User>() { /* ... */ }
class ProductAdapter : BaseAdapter<Product>() { /* ... */ }

Im ersten Beispiel implementiert jeder Adapter den Bind-Mechanismus von Grund auf neu. Beim Hinzufügen neuer Logik (Analytics, Logging) müsste jede Datei geändert werden. Eine Basisklasse beseitigt diese Duplizierung: Die gemeinsame Logik lebt an einem Ort, die spezifische Logik in den Unterklassen.

Duplizierung von Netzwerkanfragen in iOS

In iOS-Projekten wird die URLSession-Konfiguration — Header, Timeouts, Fehlerbehandlung — häufig dupliziert. Jeder Dienst erstellt seine eigene Sitzung mit wiederholten Einstellungen.

// Duplizierung: jeder Dienst konfiguriert die Sitzung neu
class UserService {
    let session = URLSession(configuration: {
        let cfg = URLSessionConfiguration.default
        cfg.timeoutIntervalForRequest = 30
        cfg.httpAdditionalHeaders = ["Authorization": "Bearer ..."]
        return cfg
    }())
}

// DRY: einheitliche Sitzungsfabrik
struct NetworkConfig {
    static var session: URLSession {
        let cfg = URLSessionConfiguration.default
        cfg.timeoutIntervalForRequest = 30
        cfg.httpAdditionalHeaders = ["Authorization": "Bearer ..."]
        return URLSession(configuration: cfg)
    }
}

Das Extrahieren der Konfiguration in eine einheitliche NetworkConfig stellt sicher, dass alle Dienste dieselben Header und Timeouts verwenden. Eine Änderung an einer Stelle wird automatisch auf alle Anfragen angewendet — dies reduziert das Fehlerrisiko beim Ändern von API-Schlüsseln oder Protokollversionen.

Wie wendet man DRY in Android und iOS an?

DRY durch Vererbung und Komposition

Vererbung ist ein natürlicher Weg, Duplizierung zu beseitigen: Gemeinsame Logik wird in eine Basisklasse verschoben, spezifische Logik in Unterklassen. In der mobilen Entwicklung führt übermäßige Verwendung von Vererbung jedoch zu starren Hierarchien, die schwer zu warten sind. Komposition (Abhängigkeitsinjektion) ist eine flexiblere Alternative.

Eine Analyse von Google I/O 2023: Modern Android Architecture zeigte, dass 76% der Google-Teams Komposition der Vererbung zur Beseitigung von Duplizierung vorziehen. Statt eines BaseViewModel mit einem Dutzend Methoden wird empfohlen, separate UseCase-Klassen für jede Geschäftsoperation zu extrahieren und sie dort zu injizieren, wo sie benötigt werden.

Wählen Sie Komposition in allen Fällen außer „ist-ein“-Beziehungen. Wenn Klasse A eine Spezialisierung von Klasse B ist — ist Vererbung angemessen. Wenn A einfach die Funktionalität von B nutzt — verwenden Sie Komposition.

DRY durch Utility-Klassen

Utility-Klassen (Extensions, Helper) sind der einfachste Weg, Duplizierung zu vermeiden. Typische Kandidaten: Datumsformatierung, E-Mail-Validierung, Einheitenumrechnung, Arbeit mit SharedPreferences/UserDefaults.

// DRY: einheitliche Datumsformatierungsfunktion
fun Date.toDisplayFormat(): String {
    val sdf = SimpleDateFormat("dd.MM.yyyy", Locale.getDefault())
    return sdf.format(this)
}

// Verwendung überall in der Anwendung
textView.text = Date().toDisplayFormat()

Die Erweiterung Date.toDisplayFormat() wird einmal deklariert und ist im gesamten Projekt verfügbar. Wenn das Format von „dd.MM.yyyy“ auf „yyyy-MM-dd“ geändert werden muss — befindet sich die Korrektur in einer Datei, nicht in jeder Activity oder jedem Fragment, in dem die Formatierung erfolgt. Das ist die Essenz von DRY.

DRY in der Gradle-Konfiguration (Android)

Multimodul-Android-Projekte duplizieren oft Abhängigkeitsversionen in jeder build.gradle. Die Lösung ist ein Version Catalog (libs.versions.toml), der alle Versionen in einer einzigen Datei zentralisiert.

Laut Android-Entwicklerdokumentation (2024) reduziert die Migration auf einen Version Catalog Abhängigkeitskonflikte um 52% und beschleunigt Builds durch einen einzigen Bearbeitungspunkt.

Implementieren Sie einen Version Catalog zu Projektbeginn oder bei der ersten Modul-Umstrukturierung. Wenn das Projekt bereits Duplizierung enthält — nehmen Sie sich einen Tag für die Migration: Sie wird sich beim nächsten Bibliotheks-Update auszahlen.

Typische Fehler bei der Befolgung von DRY

Vorzeitige Abstraktion

Vorzeitige Abstraktion ist der häufigste Fehler von Anfängern. Ein Entwickler sieht zwei ähnliche Codezeilen und extrahiert sie sofort in eine gemeinsame Funktion. Einen Monat später ändern sich die Anforderungen und die gemeinsame Funktion ist mit Parametern und Flags überladen — komplexer als die ursprüngliche Duplizierung. Die Rule of Three schützt genau davor: Abstrahieren Sie nichts, das nur ein- oder zweimal aufgetreten ist.

Martin Fowler empfiehlt in seinem Buch Refactoring (2019): „Code-Duplizierung ist nicht immer schlecht. Wissens-Duplizierung ist schlecht.“ Wenn zwei Zeilen zufällig übereinstimmen, aber unterschiedliche Konzepte ausdrücken — ist das keine Duplizierung, sondern ein Zufall. Die Rule of Three hilft, zufällige Übereinstimmungen von systematischer Duplizierung zu unterscheiden.

Bewerten Sie vor der Abstraktion die Semantik. Kopierter Code mit derselben Bedeutung — DRY-Verletzung. Code mit unterschiedlicher Bedeutung aber ähnlicher Syntax — ein Zufall, der keine Abstraktion erfordert.

Übermäßige Parametrisierung

Übermäßige Parametrisierung tritt auf, wenn eine einzelne Funktion versucht, alle möglichen Szenarien durch Flags und boolesche Parameter abzudecken. Ein solcher Code verletzt SRP und wird unlesbar. Symptom: Wenn eine Funktion mehr als zwei boolesche Parameter hat — ist das ein Code Smell für übermäßige Abstraktion.

Statt einer Funktion mit einem useCache: Boolean-Flag ist es besser, zwei separate Funktionen mit klaren Namen zu erstellen: fetchFromNetwork() und fetchFromCache(). Klarheit ist wichtiger als eine trockene Abstraktion — dies entspricht dem KISS-Prinzip.

Refaktorisieren Sie übermäßige Parametrisierung, wenn eine Funktion 3+ boolesche Parameter erreicht. Teilen Sie sie in separate Funktionen mit klaren Namen auf — jeder Aufruf wird selbstdokumentierend.