Arkitekturprinciper inom mobil utveckling: vad de är, vilka typer som finns och hur man tillämpar dem

SOLID-principer

Arkitekturprinciper — är grunden för kod av hög kvalitet. SOLID är en akronym som introducerades av Robert Martin («Farbror Bob») och beskriver fem principer för objektorienterad design. Att följa SOLID gör koden mer flexibel, testbar och motståndskraftig mot förändringar. Att bryta mot arkitekturprinciper är en av huvudorsakerna till teknisk skuld.

Låt oss undersöka varje princip. Single Responsibility Principle (SRP) — varje klass ska bara ha en anledning att ändras. Open/Closed Principle (OCP) — klasser är öppna för utbyggnad men stängda för modifiering. Liskov Substitution Principle (LSP) — objekt av undertyper ska kunna ersätta objekt av bastypen utan att bryta logiken. Interface Segregation Principle (ISP) — många specialiserade gränssnitt är bättre än ett allmänt. Dependency Inversion Principle (DIP) — beroende av abstraktioner, inte av konkreta implementationer.

Enligt SonarQube-analys (2025) förekommer brott mot SOLID-principerna i 68% av kommersiella projekt. De vanligaste problemen är SRP-brott (35%) och ISP-brott (22%). På IT Sectr implementerar vi SOLID i arkitekturgranskningsfasen — detta hjälper till att identifiera problem innan de växer till teknisk skuld.

Single Responsibility Principle (SRP)

SRP (Principen om Enskilt Ansvar) — den viktigaste och samtidigt den mest överträdda SOLID-principen. Den säger: en klass ska bara ha en anledning att ändras. Om en klass gör för mycket är den svår att testa, ändra och förstå.

Ett typiskt brott är en klass som samtidigt bearbetar data, sparar i databasen och skickar e-postmeddelanden. Exemplet nedan visar ett SRP-brott i Kotlin och hur man åtgärdar det.

// SRP-brott — klassen gör tre olika saker
class UserService {
    fun registerUser(email: String, name: String) {
        // 1. Datavalidering
        if (!email.contains("@")) throw IllegalArgumentException("Invalid email")
        
        // 2. Spara i databas
        val user = User(email, name)
        database.save(user)
        
        // 3. Skicka notifiering
        emailService.sendWelcomeEmail(email, name)
    }
}

// Åtgärd — uppdelning i tre klasser
class UserRegistrationService {
    fun register(email: String, name: String) {
        UserValidator().validate(email)
        val user = User(email, name)
        UserRepository().save(user)
        NotificationService().sendWelcome(user)
    }
}

I den korrigerade versionen är varje klass ansvarig för sin egen uppgift: UserValidator — för validering, UserRepository — för lagring, NotificationService — för notifieringar. Detta gör koden testbar och återanvändbar — du kan byta ut databasimplementationen utan att ändra valideringslogiken.

GRASP och Law of Demeter

GRASP (General Responsibility Assignment Software Patterns) — nio arkitekturprinciper för att fördela ansvar mellan objekt, beskrivna av Craig Larman. Till skillnad från SOLID svarar GRASP på frågan «vilken klass ska innehålla denna metod?». Nyckelmönster: Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, Protected Variations.

Law of Demeter (LoD, principen om minimal koppling) — en enkel regel: ett objekt ska bara kommunicera med sina omedelbara grannar. Man ska inte skriva a.getB().getC().doSomething() — detta skapar en stark koppling mellan klasser. LoD förbättrar återanvändbarheten och förenklar testning.

På IT Sectr kontrollerar vi efterlevnaden av LoD vid kodgranskning. Om en metod «går igenom» tre eller fler objekt är det en signal om att arkitekturen behöver förenklas. LoD-brott är en av de vanligaste Code Smells i stora projekt.

DRY / KISS / YAGNI

DRY (Don't Repeat Yourself), KISS (Keep It Simple, Stupid) och YAGNI (You Ain't Gonna Need It) — tre grundläggande arkitekturprinciper som varje utvecklare känner till. Trots sin enkelhet förekommer överträdelser ständigt.

DRY — duplicera inte kod. Om samma logik förekommer på två ställen, extrahera den till en gemensam metod eller klass. Duplicering är den främsta källan till buggar: en korrigering på ett ställe glöms bort att tillämpas på ett annat. DRY betyder inte att du inte kan ha liknande kod — det viktiga är att affärslogiken inte upprepas.

KISS — ju enklare, desto bättre. Komplexa lösningar med många abstraktioner och arv är ofta överdrivna. Börja med en enkel lösning och gör den mer komplex endast vid behov. YAGNI — skriv inte kod för funktionalitet som kan behövas «någon gång senare». Detta leder till svällande kodbas och ökad underhållskomplexitet.

DRY — Don't Repeat Yourself

DRY — det handlar inte bara om frånvaron av kopiera-klistra. Det är en princip enligt vilken varje kunskaps- eller logikdel ska ha en enda, otvetydig representation i systemet. Duplicering kan vara explicit (kopierad kod) och implicit (samma logik i olika lager).

På IT Sectr använder vi kodanalysmetriker för att upptäcka duplicering. Verktyg som SonarQube och Detekt visar procentandelen duplicerad kod. Ett värde över 5% är en anledning till refaktorering. Det är dock viktigt att komma ihåg: DRY bör inte uppnås till priset av felaktiga abstraktioner — ibland är det bättre att lämna två liknande kodstycken som de är om deras sammanslagning skulle försvåra förståelsen.

Separation of Concerns och Modularitet

Separation of Concerns (SoC) — en arkitekturprincip där ett system delas upp i oberoende delar (concerns), var och en löser sin egen uppgift. Ett klassiskt exempel är lagerindelning: presentation, affärslogik, dataåtkomst. Varje lager är bara beroende av lagret under.

Modularitet — den grad till vilken ett system kan delas upp i moduler. En modul är en logiskt relaterad grupp av klasser med ett väldefinierat gränssnitt. Moduler bör vara löst kopplade (low coupling) och starkt sammanhållna (high cohesion).

Sammanhållning vs Koppling

Sammanhållning (Cohesion) — ett mått på hur mycket element inom samma modul är relaterade till varandra. Hög sammanhållning är bra: en klass gör en sak och gör den bra. Låg koppling (Low coupling) — ett mått på hur oberoende moduler är av varandra. Låg koppling är bra: att ändra en modul bryter inte andra.

Ideal arkitektur är hög sammanhållning och låg koppling. I praktiken innebär detta: en klass innehåller metoder som arbetar på samma data (sammanhållning) och är endast beroende av abstraktioner, inte av konkreta implementationer (koppling). En obalans leder till «Gud-objekt» eller «spagettikod».

Teknisk skuld och Code Smell

Teknisk skuld (Technical Debt) — en metafor introducerad av Ward Cunningham som beskriver den «ränta» som ett team betalar för suboptimala arkitekturbeslut och brott mot arkitekturprinciper. Liksom finansiell skuld kan teknisk skuld vara avsiktlig (vi bestämde oss för att göra det snabbt, vi gör om det senare) och oavsiktlig (dålig arkitektur på grund av bristande erfarenhet).

Code Smell — ytliga tecken på djupa problem i koden. Termen populariserades av Martin Fowler i boken «Refactoring». Typiska Code Smells: långa metoder, stora klasser, långa anropskedjor, kodduplicering, överdriven användning av kommentarer (istället för tydlig kod).

På IT Sectr spåras teknisk skuld i Jira som separata uppgifter. Varje sprint avsätter vi 20% av tiden för refaktorering och skuldbetalning. Systematiskt arbete med teknisk skuld är det enda sättet att undvika en situation där det tar längre tid att lägga till en ny funktion än att utveckla den från grunden.