Архітектура та патерни в мобільній розробці: що це, які бувають і як застосовувати

Основні архітектурні патерни

Архітектурний патерн визначає, як розподіляються обов'язки між класами застосунку. Від вибору патерну залежить легкість додавання нових екранів та тестування коду.

MVC (Model-View-Controller)

MVC — класичний патерн, де Model відповідає за дані, View — за відображення, Controller — за логіку. В iOS MVC використовується за замовчуванням (UIViewController), в Android — Activity. Недолік — Controller часто стає «товстим» (Massive View Controller). За даними опитування iOS-розробників (Reddit, 2025), 62% називають MVC основною причиною нечитабельного коду в старих проєктах.

MVP (Model-View-Presenter)

MVP відрізняється тим, що Presenter керує View через інтерфейс, покращуючи тестованість. MVP був популярним в Android до появи Jetpack, але поступається MVVM за зручністю.

MVVM (Model-View-ViewModel)

MVVM — рекомендований Google патерн для Android та Apple для iOS. ViewModel зберігає стан, View підписується на зміни через Data Binding або @Published. ViewModel не залежить від View і легко тестується. В IT Sectr ми використовуємо MVVM як основний патерн у всіх проєктах.

MVI та VIPER

MVI — реактивний патерн, де кожна дія проходить цикл Intent → Model → View. MVI гарантує передбачуваний стан. VIPER — патерн для iOS з п'ятьма шарами (View, Interactor, Presenter, Entity, Router), що дає максимальну ізоляцію, але вимагає багато шаблонного коду.

Clean Architecture

Clean Architecture — концепція Роберта Мартіна, яка ділить застосунок на шари: зовнішні (UI, БД, мережа) залежать від внутрішніх (бізнес-логіка, сутності). В мобільній розробці Clean Architecture включає три шари: data (репозиторії), domain (Use Cases) та presentation (ViewModels, UI).

Repository Pattern — ключовий компонент Clean Architecture, що абстрагує джерело даних. Репозиторій вирішує, чи брати дані з мережі або локальної бази (Room, Core Data), і повертає єдиний формат. За даними Google (Architecture Guide, 2025), Repository Pattern рекомендується для будь-якого застосунку з мережевими запитами. Clean Architecture виправдана в проєктах від 3–5 екранів — для простих застосунків починайте з MVVM.

Породжувальні патерни

Singleton

Singleton — архітектурний патерн, що гарантує єдиний екземпляр класу та глобальну точку доступу до нього. Використовується для бази даних, менеджера налаштувань, кешу. В Kotlin створюється через object. Недолік — ускладнює тестування через глобальний стан.

Factory та Builder

Factory делегує створення об'єктів фабричному методу — замість new викликається фабрика. Builder — патерн покрокового конструювання складних об'єктів з безліччю параметрів (AlertDialog.Builder, NotificationCompat.Builder). Builder покращує читабельність та дозволяє робити об'єкти незмінними після збирання.

Структурні та поведінкові патерни

Adapter, Facade, Delegate, Protocol

Adapter — архітектурний патерн, що перетворює інтерфейс одного класу в інтерфейс, очікуваний клієнтом. В Android це RecyclerView.Adapter. Facade надає спрощений інтерфейс до складної системи — наприклад, фасад для API, що приховує деталі автентифікації. Delegate — патерн iOS, де об'єкт делегує завдання (UITableViewDelegate). Protocol — аналог інтерфейсу в Swift.

Observer та Strategy

Observer — патерн підписки на зміни: суб'єкт повідомляє підписників про зміни. В мобільній розробці Observer — основа LiveData, StateFlow, RxJava та Combine. Strategy — патерн взаємозамінних алгоритмів: ви підставляєте різну стратегію (сортування, валідація) без множинних if-else.

Впровадження залежностей та керування станом

Dependency Injection — архітектурний патерн, де об'єкт отримує залежності ззовні замість створення їх сам. Замість new Database() ви передаєте базу даних через конструктор. DI спрощує тестування — ви можете підставити Mock замість реальної БД — та заміну реалізацій. Популярні DI-фреймворки: Dagger та Hilt (Android), Swinject (iOS), Koin (Kotlin). Hilt — надбудова над Dagger, рекомендована Google, скорочує налаштування DI в 3 рази.

Service Locator — альтернатива DI з центральним реєстром залежностей. Простіший у реалізації, але приховує залежності класу, ускладнюючи тестування. Сучасні проєкти віддають перевагу DI через Hilt або Koin.

Керування станом у Flutter

У Flutter керування станом — окрема екосистема. Redux — єдиний Store зі змінами через Actions → Reducer → State. BLoC від Google розділяє події та стани через Stream. Provider — простий DI-контейнер, рекомендований Google для Flutter до 2023. Riverpod — покращений Provider, що вирішує проблеми з компіляцією та тестуванням. GetX — мікро-фреймворк з маршрутизацією, DI та станом. Для початківців Flutter-розробників ми рекомендуємо Provider або Riverpod як найбільш документовані рішення.

Принципи SOLID та DRY

Крім конкретних патернів, існують загальні принципи архітектури проєктування, які застосовні в будь-якій мові та фреймворку.

SOLID — п'ять принципів об'єктно-орієнтованого проєктування: Single Responsibility (один клас — одне завдання), Open-Closed (відкритий для розширення, закритий для зміни), Liskov Substitution (підкласи замінюють батька), Interface Segregation (маленькі інтерфейси), Dependency Inversion (залежність від абстракцій). В мобільній розробці SRP — найкорисніший принцип: кожен клас робить лише одну річ. За досвідом IT Sectr, порушення SRP — причина 70% проблем з тестуванням у комерційних проєктах.

// Пример: нарушение 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 показує, як з одного класу UserManager з чотирма обов'язками ми отримуємо чотири класи з одним обов'язком кожен. Такий код простіше тестувати, змінювати та перевикористовувати.

DRY (Don't Repeat Yourself) — уникайте дублювання коду. Виносьте повторювану логіку в спільні методи або класи. KISS (Keep It Simple, Stupid) — простота важливіша за елегантність. YAGNI (You Aren't Gonna Need It) — не пишіть код для того, що може не знадобитися. Ці принципи допомагають писати чистий, підтримуваний код без надмірності.

Платформені патерни Android

ViewModel (Android) — компонент архітектури Jetpack для зберігання UI-стану, стійкий до повороту екрана. ViewModel не містить посилань на Activity і автоматично очищається. LiveData — Observable-контейнер даних з урахуванням життєвого циклу. StateFlow — сучасна заміна LiveData на Kotlin Flow. SharedFlow — Hot Flow для одноразових подій (навігація, тости).

Data Binding та Two-Way Binding — механізми зв'язування UI та даних в Android. Data Binding оголошує зв'язок в XML, Two-Way Binding автоматично оновлює поле в ViewModel. Unidirectional Data Flow — принцип, де дані рухаються в одному напрямку: State → UI → Event → State. В IT Sectr ми використовуємо Unidirectional Data Flow у всіх нових проєктах — це знижує кількість багів від неочікуваних змін стану.