Cohesion (samenhang) in mobiele ontwikkeling: basis, niveaus en hoe te verbeteren

Wat is Cohesion

Cohesion (samenhang) — een metriek die beoordeelt hoe logisch methoden, velden en eigenschappen binnen één klasse of module met elkaar verbonden zijn. Een modul met hoge samenhang voert één taak uit en bevat alleen de elementen die nodig zijn voor de uitvoering ervan. Een modul met lage samenhang probeert meerdere dingen tegelijk te doen — methoden zijn zwak semantisch verbonden.

In de context van objectgeoriënteerd programmeren is cohesion nauw verbonden met het Single Responsibility Principle (S). Als een klasse één duidelijke verantwoordelijkheid heeft, is de cohesion meestal hoog. Als een klasse zich bezighoudt met zowel UI, bedrijfslogica als netwerkcommunicatie — is de cohesion laag en moet een dergelijke klasse worden opgesplitst in meerdere afzonderlijke klassen met een smallere verantwoordelijkheid.

Het begrijpen van cohesion helpt de ontwikkelaar bij het nemen van refactorbeslissingen. Wanneer u ziet dat er in een klasse een methode is die geen gebruik maakt van de velden van de klasse, is dit een signaal van lage samenhang. Een dergelijke methode is óf overbodig in de klasse, óf de klasse is slecht ontworpen. Streven naar hoge samenhang — is continu werk aan het verbeteren van de architectuur op elk niveau van de code.

Soorten en niveaus van samenhang

In de software-engineering worden zeven niveaus van cohesion onderscheiden, gerangschikt van slechtst naar best. Inzicht in deze schaal maakt het mogelijk om de kwaliteit van een module objectief te beoordelen en te bepalen in welke richting te bewegen bij refactoring. Hoe hoger het niveau, hoe onderhoudbaarder en begrijpelijker de code zal zijn.

Lage samenhang: toevallig, logisch en temporeel

Toevallige (coincidental) — het slechtste niveau, wanneer elementen in de module willekeurig zijn gegroepeerd, zonder enig logisch verband. Voorbeeld: de klasse Utilities, met methoden voor datumnotatie, e-mail verzenden en korting berekenen. Zo’n klasse is niet te begrijpen zonder alle methoden te lezen, en het wijzigen van één methode kan andere breken alleen omdat ze naast elkaar staan.

Logische (logical) samenhang — elementen voeren logisch verbonden, maar wezenlijk verschillende taken uit. Een klasse met methoden parseJSON, parseXML en parseCSV is logisch verbonden door het onderwerp „parsen“, maar elke methode doet fundamenteel ander werk. Probleem: bij het toevoegen van een nieuw formaat (YAML) groeit de klasse en wordt de interface opgeblazen.

Temporele (temporal) samenhang — elementen zijn gegroepeerd op uitvoeringstijd. De klasse AppInitializer, die de database configureert, de configuratie laadt, de analyse initialiseert — dit gebeurt allemaal bij het opstarten van de applicatie, maar de taken zelf zijn niet gerelateerd. Het is beter om ze te verdelen in afzonderlijke Initializers voor elk verantwoordelijkheidsgebied.

Gemiddelde samenhang: procedureel en communicatief

Procedurele (procedural) samenhang ontstaat wanneer elementen zijn verbonden door een uitvoeringsvolgorde. De module „Orderverwerking” bevat de methoden validateCart, processPayment, sendConfirmation — elke methode wordt strikt na de vorige aangeroepen. Dit is beter dan toevallige of logische samenhang, maar nog steeds niet ideaal: elke stap kan naar een aparte module worden geëxtraheerd.

Communicatieve (communicational) samenhang — elementen werken met dezelfde gegevens. De klasse UserService met methoden getUser, updateUser, deleteUser is verbonden door de gemeenschappelijke entiteit User. Dit is aanzienlijk beter dan procedurele samenhang: de klasse heeft een duidelijk domein. De meeste Repository-klassen in mobiele projecten hebben communicatieve samenhang.

Hoge samenhang: functioneel

Functionele (functional) samenhang — het hoogste niveau, wanneer elk element van de module deelneemt aan de uitvoering van één taak. De klasse PasswordValidator met de enige methode validate, die de lengte, aanwezigheid van tekens en complexiteit van het wachtwoord controleert — een voorbeeld van functionele samenhang. Als zo’n klasse verandert, is dat alleen omdat de regels voor wachtwoordvalidatie zijn gewijzigd.

Het bereiken van functionele samenhang — het hoofddoel van architecturale refactoring. Elke klasse moet precies één reden hebben om te veranderen. In mobiele ontwikkeling wordt functionele samenhang bereikt door het scheiden van afzonderlijke Use Cases, aangepaste Views, formatters en validators. Elk van deze klassen is een compleet bouwblok met een duidelijk verantwoordelijkheidsgebied.

Cohesion vs Coupling

Cohesion en coupling — twee kanten van dezelfde kwaliteit. Hoe hoger de cohesion binnen een module, hoe lager de coupling tussen modules doorgaans is. Een goed ontworpen systeem streeft tegelijkertijd naar hoge samenhang binnenin en zwakke verbondenheid naar buiten. Deze regel wordt sinds de jaren 1970 als fundamenteel beschouwd in de software-engineering.

De verhouding cohesion-coupling kan worden voorgesteld als een balans. Als een ontwikkelaar cohesion opoffert door meerdere taken in één klasse te combineren, krijgen naburige modules meer afhankelijkheden — ze moeten voor verschillende doeleinden naar deze overbelaste klasse verwijzen, wat de coupling verhoogt. En omgekeerd, het opsplitsen in kleine, sterk samenhangende klassen vermindert het aantal interactiepunten tussen modules.

In de praktijk betekent dit: wanneer u een nieuwe klasse met functionele samenhang extraheert, bevrijdt u tegelijkertijd andere modules van de noodzaak om de implementatiedetails ervan te kennen. Door bijvoorbeeld EncryptionManager in een aparte klasse met functionele samenhang te plaatsen, geeft u andere modules een eenvoudige interface encrypt/decrypt zonder dat ze de details van het encryptie-algoritme hoeven te begrijpen.

// Lage samenhang — klasse doet alles tegelijk
class UserManager {
    fun fetchAndSaveUser(id: String) { }
    fun parseUserJson(json: String): User { }
    fun displayUserName(user: User): String { }
    fun validateEmail(email: String): Boolean { }
}

// Hoge samenhang — elke klasse lost één taak op
class UserRepository {
    fun fetchUser(id: String): User { }
}

class UserJsonParser {
    fun parse(json: String): User { }
}

class UserNameFormatter {
    fun format(user: User): String { }
}

class EmailValidator {
    fun isValid(email: String): Boolean { }
}

Het voorbeeld toont het verschil: UserManager heeft logische samenhang — alle methoden gaan over gebruikers, maar elke doet fundamenteel ander werk. Na refactoring heeft elke klasse functionele samenhang en neemt de coupling af, omdat andere modules alleen afhankelijk zijn van de klasse die ze nodig hebben, niet van de hele UserManager.

Hoe samenhang in code meten

LCOM (Lack of Cohesion of Methods) — de bekendste metriek voor het meten van klassamenhang. LCOM telt hoeveel paren methoden geen gemeenschappelijke velden gebruiken. Waarde 0 betekent ideale samenhang (alle methoden werken met dezelfde velden), hoge waarde — lage samenhang. LCOM4 (verbeterde versie) houdt ook rekening met transitieve verbindingen via andere methoden.

In Android-ontwikkeling kunnen samenhangmetrieken worden verkregen via Detekt met de regel TooManyFunctions. Klassen met tientallen methoden die verschillende veldgroepen gebruiken, hebben waarschijnlijk een lage samenhang. In iOS heeft SwiftLint de regels file_length en function_body_length — indirecte indicatoren: lange bestanden en methoden duiden vaak op lage cohesion.

Handmatige beoordelingsmethode: stel de vraag „Zal deze klasse veranderen om één reden of om meerdere redenen?” Als u meer dan één onafhankelijke reden kunt noemen — heeft de klasse lage samenhang. Tweede test: „Kan deze klasse worden opgesplitst in twee onafhankelijke klassen?” Zo ja — doe het. Regelmatige controle van cohesion tijdens code-review voorkomt het ontstaan van God-klassen en vermindert technische schuld.

Hoe Cohesion in een mobiel project te verbeteren

Eerste stap — pas het Single Responsibility Principle toe. Elke klasse moet één duidelijke verantwoordelijkheid hebben. Als er in een klasse een methode is die niet tot de hoofdtaak behoort, extraheer deze dan naar een aparte klasse. De techniek Extract Class of Extract Delegate in de IDE automatiseert dit proces. Controleer na het extraheren of de oorspronkelijke klasse meer gefocust is geworden.

Tweede stap — gebruik het Facade-patroon om de interface te vereenvoudigen. Als een klasse 20 methoden biedt waarvan klanten er slechts 3-4 gebruiken, heeft de klasse waarschijnlijk een lage samenhang — ze biedt te veel verschillende functionaliteit. Groepeer de methoden per onderwerp en extraheer aparte klassen voor elke groep, en maak van de oorspronkelijke klasse een facade of verwijder deze.

Derde stap — let op veldgroepen. Als een klasse velden heeft die slechts door een deel van de methoden worden gebruikt — is dit een indicator van lage cohesion. Deel de klasse op basis van veldgroepen. Als een klasse bijvoorbeeld de velden userRepository, networkClient en analyticsTracker bevat, maar de methoden van de eerste groep gebruiken alleen userRepository en de tweede — networkClient — dan zijn dit twee verschillende klassen.

Vierde stap — vermijd het maken van ‘utility’-klassen met willekeurige static-methoden. Elke static-methode in een klasse Utils of Helpers is een kandidaat voor extractie naar een gespecialiseerde klasse. FormatUtils.dateToString kan beter worden verplaatst naar DateFormatter en ValidationUtils.isValidEmail naar EmailValidator. Dit verhoogt de cohesion van elke klasse en maakt de code zelfdocumenterend.