Arkitektur och mönster inom mobilutveckling: Vad det är, vilka typer som finns och hur man tillämpar dem

Huvudsakliga arkitekturmönster

Ett arkitekturmönster bestämmer hur ansvar fördelas mellan applikationens klasser. Valet av mönster påverkar hur lätt det är att lägga till nya skärmar och testa kod.

MVC (Model-View-Controller)

MVC är ett klassiskt mönster där Model hanterar data, View visning och Controller logik. I iOS är MVC standard (UIViewController); i Android, Activity. Nackdelen är att Controller ofta blir "massiv" (Massive View Controller). Enligt en undersökning bland iOS-utvecklare (Reddit, 2025) anger 62 % MVC som den främsta orsaken till oläslig kod i äldre projekt.

MVP (Model-View-Presenter)

MVP skiljer sig genom att Presenter hanterar View via ett gränssnitt, vilket förbättrar testbarheten. MVP var populärt i Android före Jetpack, men ligger efter MVVM i bekvämlighet.

MVVM (Model-View-ViewModel)

MVVM är det rekommenderade mönstret av Google för Android och Apple för iOS. ViewModel lagrar tillstånd och View prenumererar på ändringar via Data Binding eller @Published. ViewModel är inte beroende av View och är lätt att testa. På IT Sectr använder vi MVVM som huvudmönster i alla projekt.

MVI och VIPER

MVI är ett reaktivt mönster där varje åtgärd följer cykeln Intent → Model → View. MVI garanterar förutsägbart tillstånd. VIPER är ett iOS-mönster med fem lager (View, Interactor, Presenter, Entity, Router) som ger maximal isolering men kräver mycket standardkod.

Clean Architecture

Clean Architecture är Robert Martins koncept som delar en applikation i lager: yttre lager (UI, DB, nätverk) är beroende av inre lager (affärslogik, entiteter). Inom mobilutveckling omfattar Clean Architecture tre lager: data (förvar), domain (Use Cases) och presentation (ViewModels, UI).

Repository Pattern är en nyckelkomponent i Clean Architecture som abstraherar datakällan. Förvaret avgör om data ska hämtas från nätverket eller lokal lagring (Room, Core Data) och returnerar ett enhetligt format. Enligt Google (Architecture Guide, 2025) rekommenderas Repository Pattern för alla appar med nätverksförfrågningar. Clean Architecture är motiverad i projekt med 3–5 skärmar eller fler — för enkla appar, börja med MVVM.

Skapandemönster

Singleton

Singleton är ett arkitekturmönster som garanterar en enda instans av en klass och tillhandahåller en global åtkomstpunkt till den. Det används för databaser, inställningshanterare och cache. I Kotlin skapas det via object. Nackdelen är att det försvårar testning på grund av globalt tillstånd.

Factory och Builder

Factory delegerar objektsskapande till en fabriksmetod — istället för new anropar du fabriken. Builder är ett steg-för-steg-konstruktionsmönster för komplexa objekt med många parametrar (AlertDialog.Builder, NotificationCompat.Builder). Builder förbättrar läsbarheten och låter objekt förbli oföränderliga efter montering.

Struktur- och beteendemönster

Adapter, Facade, Delegate, Protocol

Adapter är ett arkitekturmönster som konverterar en klass gränssnitt till ett gränssnitt som klienten förväntar sig. I Android är detta RecyclerView.Adapter. Facade tillhandahåller ett förenklat gränssnitt till ett komplext system — till exempel en fasad för ett API som döljer autentiseringsdetaljer. Delegate är ett iOS-mönster där ett objekt delegerar en uppgift (UITableViewDelegate). Protocol är motsvarigheten till ett gränssnitt i Swift.

Observer och Strategy

Observer är ett prenumerationsmönster för ändringar: subjektet meddelar prenumeranter om uppdateringar. Inom mobilutveckling är Observer grunden för LiveData, StateFlow, RxJava och Combine. Strategy är ett mönster för utbytbara algoritmer: du kopplar in en annan strategi (sortering, validering) utan flera if-else-satser.

Beroendeinjektion och tillståndshantering

Dependency Injection är ett arkitekturmönster där ett objekt tar emot sina beroenden utifrån istället för att skapa dem själv. Istället för new Database() skickar du databasen via konstruktorn. DI förenklar testning — du kan använda Mock istället för en riktig databas — och underlättar byte av implementationer. Populära DI-ramverk: Dagger och Hilt (Android), Swinject (iOS), Koin (Kotlin). Hilt — ett omslag runt Dagger som rekommenderas av Google — minskar DI-installationen med 3 gånger.

Service Locator är ett alternativ till DI med ett centralt register över beroenden. Enklare att implementera, men döljer klassberoenden, vilket försvårar testning. Moderna projekt föredrar DI via Hilt eller Koin.

Tillståndshantering i Flutter

I Flutter är tillståndshantering ett eget ekosystem. Redux — en enda Store med ändringar via Actions → Reducer → State. BLoC från Google separerar händelser och tillstånd via Stream. Provider — en enkel DI-container som rekommenderas av Google för Flutter fram till 2023. Riverpod — en förbättrad Provider som löser kompilerings- och testproblem. GetX — ett mikro-ramverk med routing, DI och tillståndshantering. För nybörjare i Flutter rekommenderar vi Provider eller Riverpod som de bäst dokumenterade lösningarna.

SOLID och DRY-principer

Förutom specifika mönster finns allmänna arkitekturdesignprinciper som är tillämpliga i alla språk och ramverk.

SOLID — fem principer för objektorienterad design: Single Responsibility (en klass — en uppgift), Open-Closed (öppen för utökning, stängd för ändring), Liskov Substitution (subklasser ersätter föräldraklassen), Interface Segregation (små gränssnitt), Dependency Inversion (beroende av abstraktioner). Inom mobilutveckling är SRP den mest användbara principen: varje klass gör bara en sak. Enligt IT Sectrs erfarenhet är brott mot SRP orsaken till 70 % av testproblemen i kommersiella projekt.

// Пример: нарушение SRP
class UserManager {
    fun saveUser(user: User) { /* сохранение */ }
    fun validateEmail(email: String): Boolean { /* валидация */ }
    fun sendEmail(user: User) { /* отправка */ }
    fun formatUser(user: User): String { /* форматирование */ }
}

// Исправление: разделяем на отдельные классы
class UserRepository { fun save(user: User) {} }
class EmailValidator { fun isValid(email: String): Boolean {} }
class EmailService { fun send(user: User) {} }
class UserFormatter { fun format(user: User): String {} }

Kotlin-exemplet visar hur vi omvandlar en UserManager-klass med fyra ansvarsområden till fyra klasser med ett ansvar var. Sådan kod är lättare att testa, ändra och återanvända.

DRY (Don't Repeat Yourself) — undvik kodduplicering. Extrahera upprepad logik till delade metoder eller klasser. KISS (Keep It Simple, Stupid) — enkelhet är viktigare än elegans. YAGNI (You Aren't Gonna Need It) — skriv inte kod för något som kanske inte behövs. Dessa principer hjälper till att skriva ren, underhållbar kod utan redundans.

Android-plattformsmönster

ViewModel (Android) är en Jetpack-arkitekturkomponent för att lagra UI-tillstånd, resistent mot skärmrotation. ViewModel innehåller inga referenser till Activity och rensas automatiskt. LiveData — en observerbar databehållare med livscykelmedvetenhet. StateFlow — en modern ersättning för LiveData baserad på Kotlin Flow. SharedFlow — en Hot Flow för engångshändelser (navigering, toasts).

Data Binding och Two-Way Binding — mekanismer för att binda UI och data i Android. Data Binding deklarerar anslutningen i XML; Two-Way Binding uppdaterar automatiskt fältet i ViewModel. Unidirectional Data Flow — en princip där data flödar i en riktning: State → UI → Event → State. På IT Sectr använder vi Unidirectional Data Flow i alla nya projekt — det minskar antalet buggar orsakade av oväntade tillståndsändringar.