Architektúra és minták a mobilfejlesztésben: Mi ez, milyen típusok vannak és hogyan alkalmazzuk

Főbb architekturális minták

Az architekturális minta meghatározza, hogy a felelősségek hogyan oszlanak meg az alkalmazás osztályai között. A minta kiválasztása befolyásolja az új képernyők hozzáadásának és a kód tesztelésének könnyedségét.

MVC (Model-View-Controller)

MVC egy klasszikus minta, ahol a Model az adatokat, a View a megjelenítést, a Controller pedig a logikát kezeli. iOS-ben az MVC az alapértelmezett (UIViewController); Android-ban az Activity. Hátránya, hogy a Controller gyakran "masszívvá" válik (Massive View Controller). Egy iOS-fejlesztők körében végzett felmérés (Reddit, 2025) szerint 62% az MVC-t jelöli meg az olvashatatlan kód fő okaként régi projektekben.

MVP (Model-View-Presenter)

MVP abban különbözik, hogy a Presenter egy interfészen keresztül irányítja a View-t, javítva a tesztelhetőséget. Az MVP népszerű volt Androidban a Jetpack előtt, de kényelemben elmarad az MVVM-től.

MVVM (Model-View-ViewModel)

MVVM a Google által Androidhoz és az Apple által iOS-hez ajánlott minta. A ViewModel tárolja az állapotot, a View pedig feliratkozik a változásokra Data Binding vagy @Published segítségével. A ViewModel nem függ a View-tól és könnyen tesztelhető. Az IT Sectr-nél az MVVM-et használjuk fő mintaként minden projektben.

MVI és VIPER

MVI egy reaktív minta, ahol minden művelet az Intent → Model → View ciklust követi. Az MVI kiszámítható állapotot garantál. A VIPER egy ötrétegű iOS-minta (View, Interactor, Presenter, Entity, Router), amely maximális elkülönítést biztosít, de sok sablonkódot igényel.

Clean Architecture

Clean Architecture Robert Martin koncepciója, amely rétegekre osztja az alkalmazást: a külső rétegek (UI, adatbázis, hálózat) a belső rétegektől (üzleti logika, entitások) függnek. A mobilfejlesztésben a Clean Architecture három réteget foglal magában: data (tárolók), domain (Use Cases) és presentation (ViewModels, UI).

Repository Pattern a Clean Architecture kulcsfontosságú összetevője, amely elvonatkoztatja az adatforrást. A tároló eldönti, hogy a hálózatból vagy a helyi tárolóból (Room, Core Data) szerezze be az adatokat, és egységes formátumban adja vissza. A Google (Architecture Guide, 2025) szerint a Repository Pattern minden hálózati kérésekkel rendelkező alkalmazáshoz ajánlott. A Clean Architecture a 3–5 képernyős vagy nagyobb projektekben indokolt — egyszerű alkalmazásokhoz kezdje az MVVM-mel.

Létrehozási minták

Singleton

Singleton egy architekturális minta, amely egy osztály egyetlen példányát garantálja és globális hozzáférési pontot biztosít hozzá. Adatbázisokhoz, beállításkezelőkhöz és gyorsítótárhoz használják. Kotlinban object segítségével hozható létre. Hátránya, hogy a globális állapot miatt megnehezíti a tesztelést.

Factory és Builder

Factory az objektumok létrehozását egy gyártási módszerre bízza — a new helyett a gyárat hívja. A Builder egy lépésről lépésre történő építkezési minta összetett, sok paraméterrel rendelkező objektumokhoz (AlertDialog.Builder, NotificationCompat.Builder). A Builder javítja az olvashatóságot, és lehetővé teszi, hogy az objektumok az összeállítás után is megváltoztathatatlanok maradjanak.

Szerkezeti és viselkedési minták

Adapter, Facade, Delegate, Protocol

Adapter egy architekturális minta, amely egy osztály interfészét az ügyfél által várt interfésszé alakítja. Androidban ez a RecyclerView.Adapter. A Facade egyszerűsített interfészt biztosít egy összetett rendszerhez — például egy API-hoz készült homlokzat, amely elrejti a hitelesítés részleteit. A Delegate egy iOS-minta, ahol egy objektum egy feladatot delegál (UITableViewDelegate). A Protocol az interfész megfelelője Swiftben.

Observer és Strategy

Observer egy feliratkozási minta a változásokhoz: az alany értesíti a feliratkozókat a frissítésekről. A mobilfejlesztésben az Observer a LiveData, StateFlow, RxJava és Combine alapja. A Strategy a felcserélhető algoritmusok mintája: egy másik stratégiát (rendezés, érvényesítés) csatlakoztathat több if-else utasítás nélkül.

Függőséginjektálás és állapotkezelés

Dependency Injection egy architekturális minta, ahol egy objektum a függőségeit kívülről kapja, ahelyett hogy maga hozná létre azokat. A new Database() helyett a konstruktoron keresztül adja át az adatbázist. A DI egyszerűsíti a tesztelést — használhat Mock-ot a valódi adatbázis helyett — és megkönnyíti a megvalósítások cseréjét. Népszerű DI-keretrendszerek: Dagger és Hilt (Android), Swinject (iOS), Koin (Kotlin). A Hilt — a Google által ajánlott Dagger körüli burkoló — 3-szorosára csökkenti a DI beállítását.

Service Locator a DI alternatívája központi függőségi nyilvántartással. Egyszerűbb megvalósítani, de elrejti az osztály függőségeit, megnehezítve a tesztelést. A modern projektek a Hilt vagy Koin általi DI-t részesítik előnyben.

Állapotkezelés Flutterben

A Flutterben az állapotkezelés egy külön ökoszisztéma. Redux — egyetlen Store változásokkal Actions → Reducer → State segítségével. A Google BLoC-ja Stream-en keresztül választja el az eseményeket és állapotokat. Provider — egy egyszerű DI-konténer, amelyet a Google 2023-ig ajánlott a Flutterhez. Riverpod — egy továbbfejlesztett Provider, amely megoldja a fordítási és tesztelési problémákat. GetX — egy mikro-keretrendszer útválasztással, DI-vel és állapotkezeléssel. Kezdő Flutter-fejlesztőknek a Provider vagy Riverpod ajánljuk a legjobban dokumentált megoldásokként.

SOLID és DRY elvek

A konkrét mintákon kívül léteznek általános architektúra-tervezési elvek, amelyek bármely nyelven és keretrendszerben alkalmazhatók.

SOLID — az objektumorientált tervezés öt elve: Single Responsibility (egy osztály — egy feladat), Open-Closed (nyitott a bővítésre, zárt a módosításra), Liskov Substitution (az alosztályok helyettesíthetik a szülőosztályt), Interface Segregation (kis interfészek), Dependency Inversion (absztrakcióktól való függés). A mobilfejlesztésben az SRP a leghasznosabb elv: minden osztály csak egy dolgot csinál. Az IT Sectr tapasztalata szerint az SRP megsértése a kereskedelmi projektekben a tesztelési problémák 70%-ának oka.

// Пример: нарушение 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 {} }

A Kotlin-példa megmutatja, hogyan alakítunk át egy UserManager osztályt négy felelősséggel négy osztállyá, egyenként egy felelősséggel. Az ilyen kódot könnyebb tesztelni, módosítani és újra felhasználni.

DRY (Don't Repeat Yourself) — kerülje a kódismétlést. Vonja ki az ismétlődő logikát megosztott metódusokba vagy osztályokba. KISS (Keep It Simple, Stupid) — az egyszerűség fontosabb, mint az elegancia. YAGNI (You Aren't Gonna Need It) — ne írjon kódot olyan dologra, amire lehet, hogy nincs szükség. Ezek az elvek segítenek tiszta, karbantartható kódot írni redundancia nélkül.

Android platform minták

ViewModel (Android) egy Jetpack architektúra-összetevő az UI-állapot tárolására, ellenáll a képernyő elforgatásának. A ViewModel nem tartalmaz hivatkozásokat az Activity-re, és automatikusan törlődik. LiveData — egy megfigyelhető adattároló életciklus-tudatossággal. StateFlow — a LiveData modern helyettesítője Kotlin Flow alapokon. SharedFlow — egy Hot Flow egyszeri eseményekhez (navigáció, toast).

Data Binding és Two-Way Binding — az UI és adatok összekapcsolásának mechanizmusai Androidban. A Data Binding deklarálja a kapcsolatot XML-ben; a Two-Way Binding automatikusan frissíti a mezőt a ViewModel-ben. Unidirectional Data Flow — egy elv, ahol az adatok egy irányba áramlanak: State → UI → Event → State. Az IT Sectr-nél minden új projektben Unidirectional Data Flow-t használunk — csökkenti a váratlan állapotváltozások által okozott hibák számát.