Архитектура и паттерны в мобильной разработке: что это, какие бывают и как применять

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

Архитектурный паттерн определяет, как распределяются обязанности между классами приложения. От выбора паттерна зависит лёгкость добавления новых экранов и тестирования кода.

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 и управление состоянием

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 во всех новых проектах — это снижает количество багов от неожиданных изменений состояния.