Architektura a vzory v mobilním vývoji: co to je, jaké jsou typy a jak je používat

Hlavní architektonické vzory

Architektonický vzor určuje, jak jsou odpovědnosti rozděleny mezi třídy aplikace. Volba vzoru ovlivňuje snadnost přidávání nových obrazovek a testování kódu.

MVC (Model-View-Controller)

MVC je klasický vzor, kde Model spravuje data, View zobrazení a Controller logiku. V iOS je MVC výchozí (UIViewController); v Androidu Activity. Nevýhodou je, že Controller se často stává "masivním" (Massive View Controller). Podle průzkumu mezi iOS vývojáři (Reddit, 2025) 62% uvádí MVC jako hlavní příčinu nečitelného kódu ve starých projektech.

MVP (Model-View-Presenter)

MVP se liší tím, že Presenter spravuje View přes rozhraní, což zlepšuje testovatelnost. MVP bylo populární v Androidu před Jetpackem, ale zaostává za MVVM v pohodlí.

MVVM (Model-View-ViewModel)

MVVM je doporučený vzor od Google pro Android a od Apple pro iOS. ViewModel ukládá stav a View se přihlašuje k odběru změn prostřednictvím Data Binding nebo @Published. ViewModel není závislý na View a snadno se testuje. V IT Sectr používáme MVVM jako hlavní vzor ve všech projektech.

MVI a VIPER

MVI je reaktivní vzor, kde každá akce následuje cyklus Intent → Model → View. MVI zaručuje předvídatelný stav. VIPER je iOS vzor s pěti vrstvami (View, Interactor, Presenter, Entity, Router), poskytující maximální izolaci, ale vyžadující mnoho standardního kódu.

Clean Architecture

Clean Architecture je koncept Roberta Martina, který rozděluje aplikaci na vrstvy: vnější vrstvy (UI, DB, síť) závisí na vnitřních (obchodní logika, entity). V mobilním vývoji Clean Architecture zahrnuje tři vrstvy: data (úložiště), domain (Use Cases) a presentation (ViewModels, UI).

Repository Pattern je klíčovou součástí Clean Architecture, která abstrahuje zdroj dat. Úložiště rozhoduje, zda získat data ze sítě nebo z místního úložiště (Room, Core Data) a vrací jednotný formát. Podle Google (Architecture Guide, 2025) je Repository Pattern doporučen pro jakoukoli aplikaci se síťovými požadavky. Clean Architecture je opodstatněná v projektech s 3–5 obrazovkami nebo více — pro jednoduché aplikace začněte s MVVM.

Vytvářecí vzory

Singleton

Singleton je architektonický vzor, který zaručuje jedinou instanci třídy a poskytuje k ní globální přístupový bod. Používá se pro databáze, správce nastavení a mezipaměť. V Kotlinu se vytváří pomocí object. Nevýhodou je, že kvůli globálnímu stavu komplikuje testování.

Factory a Builder

Factory deleguje vytváření objektů na tovární metodu — místo new voláte továrnu. Builder je vzor postupného sestavování složitých objektů s mnoha parametry (AlertDialog.Builder, NotificationCompat.Builder). Builder zlepšuje čitelnost a umožňuje objektům zůstat po sestavení neměnné.

Strukturální a behaviorální vzory

Adapter, Facade, Delegate, Protocol

Adapter je architektonický vzor, který převádí rozhraní jedné třídy na rozhraní očekávané klientem. V Androidu je to RecyclerView.Adapter. Facade poskytuje zjednodušené rozhraní ke složitému systému — například fasáda pro API skrývající detaily autentizace. Delegate je iOS vzor, kde objekt deleguje úkol (UITableViewDelegate). Protocol je ekvivalent rozhraní ve Swiftu.

Observer a Strategy

Observer je vzor přihlášení k odběru změn: subjekt informuje odběratele o aktualizacích. V mobilním vývoji je Observer základem LiveData, StateFlow, RxJava a Combine. Strategy je vzor zaměnitelných algoritmů: připojíte jinou strategii (třídění, validace) bez několika příkazů if-else.

Vkládání závislostí a správa stavu

Dependency Injection je architektonický vzor, kde objekt přijímá své závislosti zvenčí místo toho, aby si je vytvářel sám. Místo new Database() předáte databázi přes konstruktor. DI zjednodušuje testování — můžete použít Mock místo skutečné databáze — a usnadňuje výměnu implementací. Populární DI frameworky: Dagger a Hilt (Android), Swinject (iOS), Koin (Kotlin). Hilt — obal kolem Daggeru doporučený Googlem — snižuje nastavení DI 3krát.

Service Locator je alternativa k DI s centrálním registrem závislostí. Jednodušší na implementaci, ale skrývá závislosti třídy, což ztěžuje testování. Moderní projekty preferují DI přes Hilt nebo Koin.

Správa stavu ve Flutteru

Ve Flutteru je správa stavu samostatný ekosystém. Redux — jediné Store se změnami přes Actions → Reducer → State. BLoC od Google odděluje události a stavy přes Stream. Provider — jednoduchý DI kontejner doporučený Googlem pro Flutter do roku 2023. Riverpod — vylepšený Provider řešící problémy s kompilací a testováním. GetX — mikro-framework s routováním, DI a správou stavu. Začínajícím Flutter vývojářům doporučujeme Provider nebo Riverpod jako nejlépe zdokumentovaná řešení.

Principy SOLID a DRY

Kromě konkrétních vzorů existují obecné principy návrhu architektury použitelné v jakémkoli jazyce a frameworku.

SOLID — pět principů objektově orientovaného návrhu: Single Responsibility (jedna třída — jeden úkol), Open-Closed (otevřená pro rozšíření, uzavřená pro změny), Liskov Substitution (podtřídy nahrazují rodičovskou třídu), Interface Segregation (malá rozhraní), Dependency Inversion (závislost na abstrakcích). V mobilním vývoji je SRP nejužitečnějším principem: každá třída dělá pouze jednu věc. Podle zkušeností IT Sectr je porušení SRP příčinou 70% problémů s testováním v komerčních projektech.

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

Příklad v Kotlinu ukazuje, jak přeměníme jednu třídu UserManager se čtyřmi odpovědnostmi na čtyři třídy s jednou odpovědností každou. Takový kód je snazší testovat, upravovat a znovu používat.

DRY (Don't Repeat Yourself) — vyhněte se duplicitě kódu. Vytahujte opakovanou logiku do sdílených metod nebo tříd. KISS (Keep It Simple, Stupid) — jednoduchost je důležitější než elegance. YAGNI (You Aren't Gonna Need It) — nepište kód pro něco, co nemusí být potřeba. Tyto principy pomáhají psát čistý, udržovatelný kód bez nadbytečnosti.

Vzory platformy Android

ViewModel (Android) je komponenta architektury Jetpack pro ukládání stavu UI, odolná vůči otáčení obrazovky. ViewModel neobsahuje reference na Activity a je automaticky čištěn. LiveData — pozorovatelný kontejner dat s vědomím životního cyklu. StateFlow — moderní náhrada za LiveData založená na Kotlin Flow. SharedFlow — Hot Flow pro jednorázové události (navigace, toasty).

Data Binding a Two-Way Binding — mechanismy pro vázání UI a dat v Androidu. Data Binding deklaruje spojení v XML; Two-Way Binding automaticky aktualizuje pole ve ViewModelu. Unidirectional Data Flow — princip, kde data tečou jedním směrem: State → UI → Event → State. V IT Sectr používáme Unidirectional Data Flow ve všech nových projektech — snižuje počet chyb způsobených neočekávanými změnami stavu.