Architectuurprincipes in mobiele ontwikkeling: wat ze zijn, welke soorten er zijn en hoe toe te passen

SOLID-principes

Architectuurprincipes — zijn de basis van kwaliteitscode. SOLID is een acroniem geïntroduceerd door Robert Martin («Uncle Bob») dat vijf principes van objectgeoriënteerd ontwerp beschrijft. Het volgen van SOLID maakt code flexibeler, testbaarder en beter bestand tegen veranderingen. Het schenden van architectuurprincipes is een van de belangrijkste oorzaken van technische schuld.

Laten we elk principe bekijken. Single Responsibility Principle (SRP) — elke klasse moet slechts één reden hebben om te veranderen. Open/Closed Principle (OCP) — klassen zijn open voor uitbreiding maar gesloten voor wijziging. Liskov Substitution Principle (LSP) — objecten van subtypes moeten objecten van het basistype kunnen vervangen zonder de logica te breken. Interface Segregation Principle (ISP) — veel gespecialiseerde interfaces zijn beter dan één algemene interface. Dependency Inversion Principle (DIP) — afhankelijkheid van abstracties, niet van concrete implementaties.

Volgens SonarQube-analyse (2025) komt schending van SOLID-principes voor in 68% van de commerciële projecten. De meest voorkomende problemen zijn SRP-schending (35%) en ISP-schending (22%). Bij IT Sectr implementeren we SOLID in de architectuurbeoordelingsfase — dit helpt problemen te identificeren voordat ze uitgroeien tot technische schuld.

Single Responsibility Principle (SRP)

SRP (Principe van Enkele Verantwoordelijkheid) — het belangrijkste en tegelijkertijd het meest geschonden SOLID-principe. Het stelt: een klasse moet slechts één reden hebben om te veranderen. Als een klasse te veel doet, is het moeilijk te testen, wijzigen en begrijpen.

Een typische schending is een klasse die tegelijkertijd gegevens verwerkt, in de database opslaat en e-mailmeldingen verzendt. Het onderstaande voorbeeld toont een SRP-schending in Kotlin en hoe deze te verhelpen.

// SRP-schending — klasse doet drie verschillende dingen
class UserService {
    fun registerUser(email: String, name: String) {
        // 1. Gegevensvalidatie
        if (!email.contains("@")) throw IllegalArgumentException("Invalid email")
        
        // 2. Opslaan in database
        val user = User(email, name)
        database.save(user)
        
        // 3. Melding verzenden
        emailService.sendWelcomeEmail(email, name)
    }
}

// Oplossing — verdeling in drie klassen
class UserRegistrationService {
    fun register(email: String, name: String) {
        UserValidator().validate(email)
        val user = User(email, name)
        UserRepository().save(user)
        NotificationService().sendWelcome(user)
    }
}

In de gecorrigeerde versie is elke klasse verantwoordelijk voor zijn eigen taak: UserValidator — voor validatie, UserRepository — voor opslag, NotificationService — voor meldingen. Dit maakt de code testbaar en herbruikbaar — u kunt de database-implementatie vervangen zonder de validatielogica te wijzigen.

GRASP en Wet van Demeter

GRASP (General Responsibility Assignment Software Patterns) — negen architectuurprincipes voor het verdelen van verantwoordelijkheid tussen objecten, beschreven door Craig Larman. In tegenstelling tot SOLID beantwoordt GRASP de vraag «welke klasse moet deze methode bevatten?». Belangrijkste patronen: Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, Protected Variations.

Wet van Demeter (LoD, principe van minimale koppeling) — een eenvoudige regel: een object mag alleen communiceren met zijn directe buren. Men moet niet a.getB().getC().doSomething() schrijven — dit creëert een sterke koppeling tussen klassen. LoD verbetert herbruikbaarheid en vereenvoudigt testen.

Bij IT Sectr controleren we de naleving van LoD tijdens Code Review. Als een methode door drie of meer objecten «gaat», is dat een signaal dat de architectuur vereenvoudigd moet worden. LoD-schending is een van de meest voorkomende Code Smells in grote projecten.

DRY / KISS / YAGNI

DRY (Don't Repeat Yourself), KISS (Keep It Simple, Stupid) en YAGNI (You Ain't Gonna Need It) — drie basisarchitectuurprincipes die elke ontwikkelaar kent. Ondanks hun eenvoud komen schendingen constant voor.

DRY — dupliceer code niet. Als dezelfde logica op twee plaatsen voorkomt, extraheer deze dan naar een gemeenschappelijke methode of klasse. Duplicatie is de belangrijkste bron van bugs: een correctie op de ene plaats wordt vergeten op een andere toe te passen. DRY betekent niet dat u geen vergelijkbare code kunt hebben — het belangrijkste is dat bedrijfslogica niet wordt herhaald.

KISS — hoe eenvoudiger, hoe beter. Complexe oplossingen met veel abstracties en overerving zijn vaak overdreven. Begin met een eenvoudige oplossing en maak het alleen complexer wanneer nodig. YAGNI — schrijf geen code voor functionaliteit die «ooit later» nodig zou kunnen zijn. Dit leidt tot opgeblazen codebase en verhoogde onderhoudscomplexiteit.

DRY — Don't Repeat Yourself

DRY — het gaat niet alleen om de afwezigheid van kopiëren en plakken. Het is een principe volgens welke elk stuk kennis of logica een enkele, ondubbelzinnige vertegenwoordiging in het systeem moet hebben. Duplicatie kan expliciet (gekopieerde code) en impliciet (dezelfde logica in verschillende lagen) zijn.

Bij IT Sectr gebruiken we code-analysemetrics om duplicatie te detecteren. Tools zoals SonarQube en Detekt tonen het percentage gedupliceerde code. Een waarde boven 5% is een reden voor refactoring. Het is echter belangrijk om te onthouden: DRY mag niet worden bereikt ten koste van verkeerde abstracties — soms kunnen twee vergelijkbare stukken code beter blijven zoals ze zijn als het combineren ervan het begrip zou compliceren.

Separation of Concerns en Modulariteit

Separation of Concerns (SoC) — een architectuurprincipe waarbij een systeem wordt verdeeld in onafhankelijke delen (concerns), die elk hun eigen taak oplossen. Een klassiek voorbeeld is laagverdeling: presentatie, bedrijfslogica, gegevenstoegang. Elke laag is alleen afhankelijk van de laag eronder.

Modulariteit — de mate waarin een systeem in modules kan worden verdeeld. Een module is een logisch gerelateerde groep klassen met een goed gedefinieerde interface. Modules moeten losjes gekoppeld (low coupling) en sterk coherent (high cohesion) zijn.

Cohesie vs Koppeling

Cohesie (Cohesion) — een maat voor hoezeer elementen binnen dezelfde module met elkaar verbonden zijn. Hoge cohesie is goed: een klasse doet één ding en doet het goed. Lage koppeling (Low coupling) — een maat voor hoe onafhankelijk modules van elkaar zijn. Lage koppeling is goed: het wijzigen van één module breekt andere niet.

Ideale architectuur is hoge cohesie en lage koppeling. In de praktijk betekent dit: een klasse bevat methoden die op dezelfde gegevens werken (cohesie) en is alleen afhankelijk van abstracties, niet van concrete implementaties (koppeling). Een onbalans leidt tot «God-objecten» of «spaghetticode».

Technische schuld en Code Smell

Technische schuld (Technical Debt) — een metafoor geïntroduceerd door Ward Cunningham die de «rente» beschrijft die een team betaalt voor suboptimale architectuurbeslissingen en schending van architectuurprincipes. Net als financiële schuld kan technische schuld opzettelijk (we hebben besloten het snel te doen, we doen het later over) en onopzettelijk (slechte architectuur door gebrek aan ervaring) zijn.

Code Smell — oppervlakkige tekenen van diepe problemen in code. De term werd gepopulariseerd door Martin Fowler in het boek «Refactoring». Typische Code Smells: lange methoden, grote klassen, lange aanroepketens, codeduplicatie, overmatig gebruik van opmerkingen (in plaats van duidelijke code).

Bij IT Sectr wordt technische schuld bijgehouden in Jira als afzonderlijke taken. Elke sprint besteden we 20% van de tijd aan refactoring en schuldaflossing. Systematisch werken aan technische schuld is de enige manier om een situatie te voorkomen waarin het toevoegen van een nieuwe functie langer duurt dan het helemaal opnieuw ontwikkelen.