SRP: vad är det, principen om enda ansvar inom utveckling

Vad är SRP (Single Responsibility Principle)?

SRP (Single Responsibility Principle) — principen om enda ansvar som säger: varje klass eller modul ska ha exakt en anledning att ändras. Detta betyder inte att en klass ska utföra exakt en operation. Det handlar om en grupp relaterade handlingar som förenas av ett ansvar inför en aktör.

Robert Martin omformulerade SRP i termer av aktörer: en klass bör endast ändras på begäran av en intressent eller en grupp människor. Om två olika aktörer begär ändring av samma klass — är ansvaret felaktigt fördelat.

Exempelvis klassen Employee, som samtidigt beräknar lön (begäran från redovisning) och genererar rapport (begäran från ledning), bryter mot SRP. Ändring av beräkningsregler kan påverka rapportgenereringen och vice versa.

Formell definition av SRP

En modul ska ha en och endast en anledning att ändras. Anledningen till förändring bestäms av aktören — den person eller det system som initierar kravet. Om krav från olika aktörer leder till ändring av samma modul — bryter modulen mot SRP.

Konceptet med aktör gör SRP till ett praktiskt verktyg för arkitektonisk analys, inte en abstrakt rekommendation. Vid design av ett system räcker det att fråga: “Vem kommer att begära ändring av denna kod?” — om svaret innehåller mer än en intressent, bör ansvaret delas upp.

Hur fungerar principen om enda ansvar

Enda ansvar realiseras genom gruppering av metoder som ändras av en anledning. Klassen blir en “samlingspunkt” för relaterad logik, inte en “schweizisk armékniv” för alla tillfällen. Detta förenklar förståelsen av koden: utvecklaren ser klassen och förstår omedelbart dess syfte.

SRP:s funktionsmekanism bygger på regeln om en förändringsaxel. Om funktionalitet kan ändras av oberoende anledningar — bör den flyttas till separata klasser. Förbindelserna mellan dessa klasser byggs genom komposition eller delegering.

Brott mot SRP manifesteras i “gud-klasser” (God Objects) som innehåller dussintals metoder som arbetar med olika data. En sådan klass är svår att testa — test av en metod kräver konfigurering av miljön för alla andra. Ändring av ett ansvar kan förstöra ett annat, vilket gör koden spröd.

I praktiken hjälper SRP utvecklare att svara på frågan “var finns denna kod?”. Om varje ansvar är isolerat i sin egen klass tar det sekunder att hitta den nödvändiga filen. I ett Android-projekt med MVVM-arkitektur innebär detta att UserViewModel endast ansvarar för användarskärmens tillstånd och UserRepository för att hämta data. En utvecklare som söker efter cache-logik går till UserCacheRepository, inte till ViewModel. En sådan organisation av kod accelererar introduktionen av nya teammedlemmar och minskar antalet fel vid refaktorering.

Varför SRP är viktigt inom mobil utveckling

Mobil utveckling ställer särskilda krav på kodens modularitet. Android Fragment eller iOS ViewController blir ofta “attraktionspunkter” för logik: hantering av klick, API-anrop, parsning av svar, uppdatering av UI — allt i en klass. SRP kräver separation av dessa ansvar.

I Android-arkitektur är SRP inbyggt i Googles rekommendationer för Jetpack: ViewModel ansvarar för skärmstatus, Repository för data, UseCase för affärslogik. Varje komponent har en anledning att ändras. I iOS-utveckling följer mönstret MVVM och Coordinator samma logik.

Efterlevnad av SRP i mobila projekt ger mätbara fördelar: minskning av klassstorlek med 40-60%, kortare code-review-tid och minskning av regressionsfel vid tillägg av ny funktionalitet. Isolerade moduler är lättare att täcka med enhetstester och återanvända i andra skärmar.

SRP:s påverkan på testning

Enhetstester av klasser som följer SRP kräver färre mock-objekt och konfigurationer. Om en klass har ett ansvar är dess beroenden begränsade. Testet kontrollerar ett beteende, inte en kombination av flera orelaterade scenarier.

Enligt rapporten från Google Testing Blog (2023) visar klasser med enda ansvar 35% högre testtäckning jämfört med aggregerande klasser. Utvecklare skriver mer villigt tester för små, begripliga moduler.

Exempel på SRP i Android och iOS

Betrakta en typisk Android-klass som bryter mot SRP — den laddar data, parsar svaret och uppdaterar UI. Efter refaktorering är varje ansvar isolerat i en separat komponent.

// SRP-brott: en klass gör allt
class BadUserProfileActivity {
    fun loadUser(userId: Int) {
        // HTTP-förfrågan
        // JSON-parsning
        // UI-uppdatering
        // Spara i databas
    }
}

// Efter SRP-tillämpning
class UserRepository {
    fun getUser(userId: Int): User
}

class UserViewModel {
    private val repo: UserRepository
    fun loadUser(userId: Int) { }
}

class UserProfileFragment {
    fun render(user: User) { }
}

Liknande exempel på iOS Swift med separation av nätverkslager och presentationslager:

// SRP-brott: ViewController hanterar data och UI
class BadProfileViewController: UIViewController {
    func viewDidLoad() {
        // URLSession-förfrågan
        // JSON-avkodning
        // Etikettuppdatering
    }
}

// Efter SRP-tillämpning
protocol UserServiceProtocol {
    func fetchUser(id: Int) async throws -> User
}

class ProfileViewModel {
    private let service: UserServiceProtocol
    func loadProfile(id: Int) { }
}

class ProfileViewController: UIViewController {
    func display(user: User) { }
}

SRP-refaktorering komplicerar inte arkitekturen — den omfördelar ansvar. Mängden kod kan till och med minska genom eliminering av dubbletter. Varje ny klass har ett tydligt syfte och kan utvecklas oberoende.

Komposition som alternativ till arv

Komposition hjälper till att följa SRP där arv skapar onödiga kopplingar. Istället för en superklass med dussintals metoder får underklassen en uppsättning specialiserade objekt via konstruktorn. Varje objekt ansvarar för sin egen funktionalitet.

I Android-utveckling tillåter mönstret Decorator att lägga till ansvar utan att ändra den ursprungliga klassen. I iOS separerar Middleware-kedjan i nätverkslagret loggning, cachning och autentisering i separata moduler.

Typiska SRP-brott och deras konsekvenser

Det vanligaste brottet — “God Class”: en klass som hanterar databas, skickar notifikationer, genererar rapporter och bearbetar användarinmatning. En sådan klass blir en flaskhals i projektet: varje ändring kräver fullständig regressionstestning.

Inom mobil utveckling orsakas SRP-brott av blandning av affärslogik och UI-logik i Activity, Fragment eller ViewController. När onClickListener-metoden samtidigt validerar data, anropar API och uppdaterar knappars synlighet — är detta ett direkt brott mot principen om enda ansvar.

Konsekvenser av SRP-brott inkluderar: svårighet med parallell utveckling (konflikter i en fil), försvårad enhetstestning, hög kostnad för ändringar och minskad kodläsbarhet. Projekt med systematiskt SRP-brott kräver 2-3 gånger mer tid för att lägga till ny funktionalitet.

Indikatorer på SRP-brott i kod

SRP-brott kan fastställas genom indirekta tecken: en klass innehåller mer än 200 rader, importerar moduler från olika lager av applikationen (UI + network + database), har mer än 5 publika metoder med olika teman. Kohesionsmetrik — en statistisk indikator: låg kohesion av metoder inom en klass indikerar SRP-brott.

För att upptäcka SRP-brott är det användbart att använda statiska analysverktyg: för Android — Detekt med regeln TooManyFunctions, för iOS — SwiftLint med regeln file_length. Dessa verktyg markerar klasser som överskrider tröskelvärden för storlek och komplexitet.

Refaktorering av klasser som bryter mot SRP utförs via Extract Class eller Extract Delegate: en grupp relaterade metoder flyttas till en separat klass och den ursprungliga klassen delegerar anrop till dem. Gradvis tillämpning av sådana refaktoreringar omvandlar “God Class” till en uppsättning löst kopplade moduler, var och en med ett ansvar. Ett sådant tillvägagångssätt möjliggör förbättring av arkitekturen utan att stoppa utvecklingen — refaktorering utförs iterativt, en modul i taget.