SoC inom mobilutveckling: vad det är, principer och ansvarsfördelning

Vad betyder förkortningen SoC

SoC står för Separation of Concerns — "ansvarsfördelning" eller "separering av intresseområden". I programmeringssammanhang avser termen concern vilken separerbar funktionalitet som helst: visning av användargränssnitt, bearbetning av klick, datavalidering, nätverkskommunikation eller arbete med databas. SoC-principen föreskriver gruppering av kod kring dessa områden så att ändringar i ett inte påverkar de andra.

Förkortningen SoC används flitigt i teknisk litteratur, arkitekturdiskussioner och dokumentation av ramverk. I dokumentationen för Android Architecture Components nämns SoC upprepade gånger som motivation för att separera ViewModel och View. Inom iOS-communityn används termen när man diskuterar problemet med Massive View Controller — en direkt konsekvens av avsaknaden av SoC.

Det är viktigt att förstå att SoC inte är en engångsåtgärd utan en kontinuerlig process. När applikationen växer uppstår nya ansvarsområden och arkitekturen måste omprövas. En bra kodbas går igenom flera iterationer av uppdelning innan den når ett stabilt tillstånd där varje concern är isolerad och hanterbar.

SoC vs Separation of Concerns

Separation of Concerns och dess förkortning SoC betecknar samma princip. Skillnaden ligger bara i användningssammanhanget: det fullständiga namnet används i formella dokument, utbildningsmaterial och vid första förklaringen av konceptet för nya utvecklare. SoC är bekvämt i tekniska diskussioner, kodgranskningar och dokumentation där korthet är viktigt.

I professionell miljö är båda termerna utbytbara. En utvecklare kan säga "här är SoC brutet" eller "det här bryter mot Separation of Concerns" — innebörden förändras inte. I platsannonser och arkitekturkrav förekommer dock oftare det fullständiga namnet, medan förkortningen används i chattar och kodgranskningar. Kännedom om båda varianterna är nödvändig för en bekväm inträde i branschen.

Det finns terminologisk förvirring: förkortningen SoC används även i hårdvarusammanhang för System-on-a-Chip (system på ett chip). Inom mobilutveckling är sammanhanget alltid tydligt från omgivningen — om diskussionen gäller kodarkitektur handlar det om Separation of Concerns. I denna artikel hänvisar SoC överallt till principen om ansvarsfördelning.

Hur SoC tillämpas i mobil arkitektur

Tre-skiktsarkitektur — det vanligaste sättet att implementera SoC i mobila applikationer. Den delar upp koden i Presentation (UI), Domain (affärslogik) och Data (arbete med källor). Varje lager innehåller strikt definierade klassTyper och är isolerat från grannar via gränssnitt. Detta tillvägagångssätt är lika effektivt för iOS-, Android- och Flutter-projekt.

Presentationslager och ViewModel

View och ViewModel utgör presentationslagret. View ansvarar för att rendera gränssnittet och förmedla användarhändelser. ViewModel lagrar skärmens tillstånd och omvandlar data från Domain-lagret till ett format redo för visning. ViewModel har inga referenser till Activity, Fragment eller UIViewController — detta säkerställer SoC mellan UI och logik.

Till exempel i Android Jetpack överlever ViewModel skärmrotation medan UI återskapas. Utan SoC skulle vi behöva spara tillstånd i Activity, vilket blandar livscykelhantering med data. ViewModel löser denna uppgift isolerat och demonstrerar en ren implementering av principen om ansvarsfördelning.

Domain-lager och Use Cases

Use Cases innehåller affärsregler oberoende av plattform. Detta lager importerar inte Android SDK, iOS UIKit eller Flutter-ramverk. Use Case hämtar data från Repository, tillämpar affärslogik på dem och returnerar resultatet. Tack vare SoC kan ett Use Case återanvändas på olika skärmar och plattformar.

Ett klassiskt exempel — ValidateAndSaveUseCase för registreringsformulär. Det kontrollerar korrektheten av e-post och lösenord, anropar UserRepository för lagring och returnerar ValidationResult. Varken UI eller databasen känner till valideringsreglerna — de är koncentrerade på ett ställe, vilket förenklar deras ändring.

Data-lager och Repository

Repository abstraherar datakällor från resten av applikationen. ViewModel vet inte var data kommer ifrån — REST API, GraphQL, lokal databas eller cache. Repository bestämmer vilken källa som ska användas och döljer denna logik bakom ett gränssnitt. Detta är SoC mellan datainsamling och konsumtion.

DataSource ger en ännu djupare uppdelning: RemoteDataSource ansvarar endast för HTTP-förfrågningar, LocalDataSource — för arbete med Room, CoreData eller SharedPreferences. Repository kombinerar dem med tillämpning av cachningsstrategier. Varje DataSource kan oberoende bytas ut, vilket är kritiskt vid migrering mellan servrar eller databaser.

Ett sådant flernivå DataSource-system implementerar SoC på infrastrukturnivå: nätverkskommunikation, lokal lagring och cachning — separata concerns, var och en med sin egen logik och livscykel. Vid byte av HTTP-klient ändras endast RemoteDataSource, medan Repository och högre lager förblir orörda, vilket bekräftar det praktiska värdet av ansvarsfördelning.

SoC i arkitekturmönster

MVP (Model-View-Presenter) — ett av de första mönstren som explicit implementerar SoC inom mobilutveckling. Presenter innehåller logiken och hanterar View via ett gränssnitt. View är passiv — den visar bara vad Presenter säger. Uppdelningen förenklar testning: Presenter testas utan emulator, och View förblir så enkel att det inte finns något att gå sönder.

MVVM lade till reaktiv bindning: View prenumererar på ändringar i ViewModel via Observable eller StateFlow. ViewModel lagrar ingen referens till View, vilket eliminerar risken för minnesläckor och separerar concerns ännu starkare. I Android blev MVVM standard tack vare Jetpack ViewModel och LiveData, i iOS — tack vare Combine och RxSwift.

Clean Architecture av Robert Martin för SoC till en radikal uppdelning i ringar. Den yttre ringen (ramverk och drivrutiner) är beroende av den inre (entiteter), men inte tvärtom. I praktiken implementerar mobilprojekt sällan alla fyra ringar — Domain- och Data-lager runt Presentation är tillräckliga. Men själva principen om beroende "inåt" ger betydande fördelar vid byte av ramverk.

// View — endast visning, utan logik
final class LoginViewController: UIViewController {
    let viewModel: LoginViewModel

    func loginTapped() {
        viewModel.login(emailField.text, passwordField.text)
    }
}

// ViewModel — innehåller skärmlogik, känner inte till UIKit
final class LoginViewModel {
    private let loginUseCase: LoginUseCase

    func login(email: String?, password: String?) {
        loginUseCase.execute(email, password)
    }
}

// Use Case — affärslogik, oberoende av plattform
final class LoginUseCase {
    private let repo: AuthRepository

    func execute(email: String?, password: String?) {
        guard let e = email, let p = password else { return }
        repo.authenticate(e, p)
    }
}

Exemplet visar tre nivåer av SoC: LoginViewController förmedlar bara händelser, LoginViewModel hanterar tillstånd, LoginUseCase innehåller affärsregler. Varje klass testas oberoende och byte av UI-ramverk påverkar inte Use Case.

Typiska SoC-brott i mobilprojekt

Massive View Controller — det vanligaste SoC-brottet i iOS. En klass som hanterar UI, bearbetar nätverksförfrågningar, parsar JSON och lagrar data bryter mot principen på alla nivåer. Lösning — flytta ut varje ansvar till en separat komponent: NetworkingService, JSONParser, CoreDataStack, och lämna endast View-hantering till ViewController.

I Android finns ett analogt problem — God Activity eller God Fragment. En aktivitet som laddar data, validerar formulär, visar dialoger och uppdaterar UI. Behandlas genom att införa ViewModel och Repository som tar över tillstånds- och datahantering. ViewModel skyddar även mot dataförlust vid skärmrotation.

Det tredje brottet — blandning av plattforms- och affärskod. Till exempel att placera en HTTP-förfrågan direkt i en SwiftUI View eller Android Composable. Detta gör koden ompotterbar och svår att testa. Rätt tillvägagångssätt — flytta förfrågan till Repository som anropas via Use Case, och View prenumererar bara på resultatet. Varje element i systemet löser sin egen uppgift och överskrider inte sina gränser.