DRY in mobiele ontwikkeling — wat is het, principe en waarom duplicatie schadelijk is

Wat is DRY?

DRY (Don't Repeat Yourself) — een ontwikkelingsprincipe dat eenmalige opslag van elk kenniselement in het project vereist. Dit betekent dat elke logica, configuratie of metadata exact op één plaats moet bestaan.

De term is geïntroduceerd door Andy Hunt en Dave Thomas in 1999 in het boek „The Pragmatic Programmer”. De auteurs definieerden DRY als „elk kennisonderdeel moet een unieke, consistente representatie in het systeem hebben”. Het tegenovergestelde van DRY — de WET-benadering (Write Everything Twice), waar duplicatie als norm wordt beschouwd.

Volgens onderzoek van University of California, Davis (2019) besteden projecten met een hoog niveau van code-duplicatie 42% meer tijd aan het oplossen van bugs. De reden is dat de ontwikkelaar alle kopieën van hetzelfde fragment moet vinden en wijzigen — en bij handmatig zoeken zijn omissies onvermijdelijk.

Pas DRY toe als kwaliteitscriterium voor code. Als je merkt dat hetzelfde patroon drie keer in het project voorkomt — extraheer het dan in een abstractie, zonder te wachten op de vierde herhaling.

Verschil tussen DRY en het single-responsibility principe

Single Responsibility Principle (SRP) uit SOLID stelt dat een klasse één reden voor wijziging moet hebben. DRY is breder: het omvat niet alleen klassen, maar ook gegevens, configuratie, documentatie en zelfs bedrijfsregels. SRP gaat over verantwoordelijkheidsgrenzen, DRY — over het onaanvaardbaar zijn van kopiëren.

In mobiele ontwikkeling is dit verschil bijzonder merkbaar. Als dezelfde bedrijfsregel (belastingberekening, datumopmaak) wordt herhaald in Android- en iOS-onderdelen — is dit een schending van DRY, ook al wordt SRP formeel binnen elk platform nageleefd. Oplossing — gemeenschappelijke logica extraheren in een gedeelde module (KMM, C++).

Volgens het rapport Google Android Architecture Guidelines (2023) verminderen teams die gemeenschappelijke modules gebruiken voor bedrijfslogica het aantal bugs bij wijziging van vereisten met 37% in vergelijking met projecten met logica-duplicatie tussen platforms.

Waarom is code-duplicatie gevaarlijk?

Duplicatie — de belangrijkste bron van technische schuld in mobiele projecten. Elke kopie van code creëert een verborgen afhankelijkheid: om het gedrag te wijzigen, moeten alle kopieën worden gevonden en bijgewerkt. Het missen van zelfs maar één betekent een bug.

Beschouw een klassieke situatie: in een Android-app wordt datumopmaak uitgevoerd in drie verschillende Activity's. Bij de overstap naar een nieuw formaat (bijv. ISO 8601) corrigeert de ontwikkelaar twee bestanden, vergeet de derde — en de gebruiker ziet de datum in het oude formaat. De gebruikersbeoordeling van de app daalt en het vinden van de bug duurt twee keer zo lang.

Onderzoek van Google Research (2020) toonde aan: 68% van de kritieke bugs in mobiele apps houdt verband met niet-synchrone wijziging van gedupliceerde code. De kosten van het oplossen van zo'n bug in productie zijn 4,5 keer hoger dan wanneer de code vanaf het begin uniform was geweest.

Gebruik een statische analyser (Detekt, SwiftLint) met regels die copy-paste-detectie verbieden. Configureer CI zo dat pull-requests met duplicatie van meer dan N regels niet door review komen zonder onderbouwing.

DRY in mobiele ontwikkeling: praktische voorbeelden

Duplicatie van UI-logica in Android

Een typisch anti-patroon — het kopiëren van RecyclerView-adapter met kleine wijzigingen. In plaats van één universele adapter met configuratie maken ontwikkelaars een aparte klasse voor elk scherm. Refactoring met extractie van een gemeenschappelijke basisklasse verkort de code met 30–50%.

// Duplicatie: twee afzonderlijke adapters
class UserAdapter {
    fun bind(item: User) { /* ... */ }
}
class ProductAdapter {
    fun bind(item: Product) { /* ... */ }
}

// DRY-refactoring: gemeenschappelijke basisklasse
abstract class BaseAdapter<T> {
    abstract fun bind(item: T)
}
class UserAdapter : BaseAdapter<User>() { /* ... */ }
class ProductAdapter : BaseAdapter<Product>() { /* ... */ }

In het eerste voorbeeld implementeert elke adapter het bind-mechanisme opnieuw. Bij het toevoegen van nieuwe logica (analytics, logging) moeten alle bestanden worden gewijzigd. De basisklasse elimineert deze duplicatie: gemeenschappelijke logica leeft op één plaats, specifieke logica in de overervende klassen.

Duplicatie van netwerkverzoeken in iOS

In iOS-projecten wordt vaak de URLSession-configuratie gedupliceerd — headers, time-outs, foutafhandeling. Elke service maakt zijn eigen sessie met herhalende instellingen.

// Duplicatie: elke service configureert de sessie opnieuw
class UserService {
    let session = URLSession(configuration: {
        let cfg = URLSessionConfiguration.default
        cfg.timeoutIntervalForRequest = 30
        cfg.httpAdditionalHeaders = ["Authorization": "Bearer ..."]
        return cfg
    }())
}

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

Het extraheren van de configuratie in een uniforme NetworkConfig garandeert dat alle services dezelfde headers en time-outs gebruiken. Een wijziging op één plaats wordt automatisch toegepast op alle verzoeken — dit vermindert het risico op fouten bij het wijzigen van de API-sleutel of protocolversie.

Hoe DRY toepassen in Android en iOS?

DRY door overerving en compositie

Overerving — een natuurlijke manier om duplicatie te elimineren: gemeenschappelijke logica wordt naar een basisklasse verplaatst en specifieke logica naar overervende klassen. In mobiele ontwikkeling leidt misbruik van overerving echter tot starre hiërarchieën die moeilijk te onderhouden zijn. Compositie (dependency injection) — een flexibeler alternatief.

Analyse van Google I/O 2023: Modern Android Architecture toonde aan dat 76% van de Google-teams compositie verkiest boven overerving voor het elimineren van duplicatie. In plaats van BaseViewModel met tien methoden wordt aanbevolen aparte UseCase-klassen te maken voor elke bedrijfsoperatie en deze te injecteren waar nodig.

Kies compositie in alle gevallen behalve „is-een”-relaties. Als klasse A een specialisatie is van klasse B — is overerving geschikt. Als A alleen de functionaliteit van B gebruikt — gebruik dan compositie.

DRY door utility-klassen

Utility-klassen (Extensions, Helpers) — de eenvoudigste manier om duplicatie te voorkomen. Typische kandidaten: datumopmaak, e-mailvalidatie, eenheidsconversie, werken met SharedPreferences/UserDefaults.

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

// Gebruik op elke plek in de applicatie
textView.text = Date().toDisplayFormat()

De extensie Date.toDisplayFormat() wordt eenmalig gedeclareerd en is beschikbaar in het hele project. Als het formaat moet worden gewijzigd van „dd.MM.yyyy” naar „yyyy-MM-dd” — correctie in één bestand, niet in elke Activity of Fragment waar opmaak voorkomt. Dit is precies de essentie van DRY.

DRY in Gradle-configuratie (Android)

Multi-module Android-projecten dupliceren vaak afhankelijkheidsversies in elke build.gradle. Oplossing — version catalog (libs.versions.toml), die alle versies in één bestand centraliseert.

Volgens Android Developer Documentation (2024) vermindert migratie naar version catalog afhankelijkheidsconflicten met 52% en versnelt het bouwen door een enkel correctiepunt.

Implementeer version catalog aan het begin van het project of bij de eerste reorganisatie van modules. Als het project al duplicatie bevat — wijs één dag toe voor migratie: het zal zich terugbetalen bij de volgende bibliotheekupdate.

Veelgemaakte fouten bij het volgen van DRY

Voortijdige abstractie

Voortijdige abstractie — de meest voorkomende fout van beginners. De ontwikkelaar ziet twee vergelijkbare coderegels en extraheert ze onmiddellijk in een gemeenschappelijke functie. Na een maand veranderen de vereisten en de gemeenschappelijke functie raakt overladen met parameters en vlaggen — wordt complexer dan de oorspronkelijke duplicatie. Rule of Three beschermt precies hiertegen: abstraheer niet wat een- of tweemaal is verschenen.

Martin Fowler beveelt in het boek Refactoring (2019) aan: „Code-duplicatie is niet altijd slecht. Kennisduplicatie is slecht”. Als twee regels toevallig overeenkomen maar verschillende concepten uitdrukken — is het geen duplicatie, maar toeval. Rule of Three helpt toevallige overeenkomst te onderscheiden van systematische duplicatie.

Evalueer de semantiek voordat je abstraheert. Gekopieerde code met dezelfde betekenis — schending van DRY. Code met verschillende betekenissen maar vergelijkbare syntaxis — toeval dat geen abstractie vereist.

Overmatige parametrisatie

Overmatige parametrisatie ontstaat wanneer één functie probeert alle mogelijke scenario's te dekken via vlaggen en Booleaanse parameters. Zulke code schendt SRP en wordt onleesbaar. Symptoom: als een functie meer dan twee Booleaanse parameters heeft — is dit een codegeur (code smell) van overmatige abstractie.

In plaats van één functie met de vlag useCache: Boolean, kun je beter twee aparte functies met duidelijke namen maken: fetchFromNetwork() en fetchFromCache(). Explicietheid is belangrijker dan droge abstractie — dit sluit aan bij het KISS-principe.

Refactor overmatige parametrisatie wanneer de functie 3+ Booleaanse parameters bereikt. Verdeel in aparte functies met duidelijke namen — elke aanroep wordt zelfdocumenterend.