Kohesion (Cohesion) i mobilutveckling: grunder, nivåer och hur du förbättrar den

Vad är Cohesion

Cohesion (kohesion) — ett mått som utvärderar hur logiskt sammanlänkade metoder, fält och egenskaper är inom en klass eller modul. En modul med hög kohesion utför en uppgift och innehåller endast de element som är nödvändiga för att utföra den. En modul med låg kohesion försöker göra flera saker samtidigt — metoder är svagt sammanlänkade i betydelse.

I sammanhanget av objektorienterad programmering är kohesion nära kopplad till Single Responsibility Principle (S). Om en klass har ett tydligt ansvar är dess kohesion vanligtvis hög. Om klassen hanterar både UI, affärslogik och nätverksarbete är kohesionen låg och en sådan klass bör delas upp i flera separata klasser med snävare ansvar.

Förståelse av cohesion hjälper utvecklaren att fatta beslut om refaktorisering. När du ser att en klass har en metod som inte använder klassens fält är det en signal om låg kohesion. En sådan metod är antingen överflödig i klassen eller så är klassen felaktigt designad. Strävan efter hög kohesion är ett kontinuerligt arbete med att förbättra arkitekturen på varje kodnivå.

Typer och nivåer av kohesion

Inom programvaruteknik urskiljs sju nivåer av kohesion, från den sämsta till den bästa. Förståelse av denna skala möjliggör objektiv bedömning av modulens kvalitet och förståelse av riktningen vid refaktorisering. Ju högre nivå, desto mer underhållbar och begriplig blir koden.

Låg kohesion: tillfällig, logisk och tidsmässig

Tillfällig (coincidental) — den sämsta nivån, när element i en modul grupperas slumpmässigt utan någon logisk koppling. Exempel: klassen Utilities, där metoder för datumformatering, e-postsändning och beräkning av rabatt samlats. En sådan klass kan inte förstås utan att läsa alla metoder, och en ändring av en metod kan bryta andra bara för att de ligger bredvid varandra.

Logisk (logical) kohesion — element utför logiskt relaterade men till sin natur olika uppgifter. En klass med metoderna parseJSON, parseXML och parseCSV är logiskt kopplad till temat “parsning”, men varje metod gör helt olika arbete. Problem: när ett nytt format (YAML) läggs till växer klassen och dess gränssnitt blir uppsvällt.

Tidsmässig (temporal) kohesion — element grupperas efter exekveringstid. Klassen AppInitializer, som konfigurerar databasen, laddar konfigurationen, initierar analys — allt sker vid applikationens start, men uppgifterna i sig är inte relaterade. Bättre att dela upp dem i separata Initializers för varje ansvarsområde.

Medelhög kohesion: proceduriell och kommunikativ

Proceduriell (procedural) kohesion uppstår när element förenas av exekveringssekvens. Modulen “Orderhantering” innehåller metoderna validateCart, processPayment, sendConfirmation — varje metod anropas strikt efter föregående. Detta är bättre än tillfällig eller logisk kohesion, men fortfarande inte idealiskt: varje steg kan flyttas till en separat modul.

Kommunikativ (communicational) kohesion — element arbetar med samma data. Klassen UserService med metoderna getUser, updateUser, deleteUser förenas av den gemensamma entiteten User. Detta är avsevärt bättre än proceduriell kohesion: klassen har ett tydligt ämnesområde. De flesta Repository-klasser i mobilprojekt har kommunikativ kohesion.

Hög kohesion: funktionell

Funktionell (functional) kohesion — den högsta nivån, när varje element i modulen deltar i utförandet av en uppgift. Klassen PasswordValidator med en enda metod validate, som kontrollerar längd, förekomst av tecken och lösenordets komplexitet — ett exempel på funktionell kohesion. Om en sådan klass ändras är det bara för att reglerna för lösenordsvalidering har ändrats.

Att uppnå funktionell kohesion är huvudmålet för arkitektonisk refaktorisering. Varje klass bör ha exakt en anledning att ändras. I mobilutveckling uppnås funktionell kohesion genom att separera Use Cases, anpassade vyer, formatterare och validerare. Varje sådan klass är en komplett byggsten med ett tydligt ansvarsområde.

Cohesion vs Coupling

Cohesion och coupling — två sidor av samma kvalitet. Ju högre kohesion inom en modul, desto lägre är vanligtvis kopplingen mellan moduler. Ett väldesignat system strävar samtidigt efter hög kohesion internt och svag koppling externt. Denna regel anses vara grundläggande inom programvaruteknik sedan 1970-talet.

Förhållandet cohesion-coupling kan ses som en balans. Om utvecklaren offrar kohesion genom att kombinera flera uppgifter i en klass, får närliggande moduler fler beroenden — de måste vända sig till denna överbelastade klass för olika ändamål, vilket ökar kopplingen. Omvänt minskar uppdelning i små klasser med hög kohesion antalet interaktionspunkter mellan moduler.

I praktiken innebär detta: när du extraherar en ny klass med funktionell kohesion befriar du samtidigt andra moduler från behovet att känna till dess implementationsdetaljer. Till exempel, genom att extrahera EncryptionManager till en separat klass med funktionell kohesion ger du andra moduler ett enkelt encrypt/decrypt-gränssnitt utan att de behöver förstå detaljerna i krypteringsalgoritmen.

// Låg kohesion — en klass gör allt på en gång
class UserManager {
    fun fetchAndSaveUser(id: String) { }
    fun parseUserJson(json: String): User { }
    fun displayUserName(user: User): String { }
    fun validateEmail(email: String): Boolean { }
}

// Hög kohesion — varje klass löser en uppgift
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 { }
}

Exemplet visar skillnaden: UserManager har logisk kohesion — alla metoder handlar om användare, men varje metod gör helt olika arbete. Efter refaktorisering har varje klass funktionell kohesion och kopplingen minskar eftersom andra moduler bara är beroende av den klass de behöver, inte hela UserManager.

Hur man mäter kohesion i kod

LCOM (Lack of Cohesion of Methods) — det mest kända måttet för att mäta kohesion i en klass. LCOM beräknar hur många metodpar som inte använder gemensamma fält. Värdet 0 innebär idealisk kohesion (alla metoder arbetar med samma fält), högt värde innebär låg kohesion. LCOM4 (förbättrad version) tar hänsyn till transitiva kopplingar via andra metoder.

I Android-utveckling kan kohesionsmått erhållas via Detekt med regeln TooManyFunctions. Klasser med ett tiotal metoder som använder olika fältgrupper har troligen låg kohesion. I iOS har SwiftLint reglerna file_length och function_body_length — indirekta indikatorer: långa filer och metoder signalerar ofta låg kohesion.

Manuell bedömningsmetod: ställ frågan “Kommer denna klass att ändras av en anledning eller flera?” Om du kan ange mer än en oberoende anledning har klassen låg kohesion. Andra testet: “Kan denna klass delas upp i två oberoende klasser?” Om ja — gör det. Regelbunden kontroll av kohesion vid kodgranskning förhindrar uppkomsten av Gud-klasser och minskar teknisk skuld.

Hur man förbättrar Cohesion i ett mobilprojekt

Första steget — tillämpa principen om Single Responsibility. Varje klass bör ha ett tydligt ansvar. Om en klass har en metod som inte hör till dess huvuduppgift, flytta den till en separat klass. Tekniken Extract Class eller Extract Delegate i IDE automatiserar denna process. Efter extrahering, kontrollera om den ursprungliga klassen har blivit mer fokuserad.

Andra steget — använd mönstret Facade för att förenkla gränssnittet. Om en klass tillhandahåller 20 metoder, varav klienter bara använder 3-4, har klassen troligen låg kohesion — den erbjuder för mycket olika funktionalitet. Gruppera metoder efter ämne och extrahera separata klasser för varje grupp, gör den ursprungliga klassen till en fasad eller ta bort den.

Tredje steget — var uppmärksam på fältgrupper. Om en klass har fält som bara används av en del av metoderna är detta en indikator på låg kohesion. Dela klassen efter fältgrupper. Till exempel, om klassen innehåller fälten userRepository, networkClient och analyticsTracker, men den första gruppens metoder bara använder userRepository medan den andra gruppens bara använder networkClient — det är två olika klasser.

Fjärde steget — undvik att skapa “verktygs”-klasser med godtyckliga statiska metoder. Varje statisk metod som finns i en klass Utils eller Helpers är en kandidat för extrahering till en specialiserad klass. FormatUtils.dateToString är bättre att flytta till DateFormatter och ValidationUtils.isValidEmail till EmailValidator. Detta ökar varje klass kohesion och gör koden självdokumenterande.