Separation of Concerns у мобільній розробці — що це таке, принципи та застосування

Що таке Separation of Concerns

Separation of Concerns — це принцип декомпозиції програмної системи на незалежні частини, кожна з яких вирішує одну задачу. Термін concern (область відповідальності) позначає будь-яку відокремлювану частину функціональності: відображення екрану, обробка натискання, валідація даних або мережева взаємодія. Принцип наказує групувати код так, щоб зміни в одній області не вимагали змін в інших.

У мобільній розробці SoC проявляється на кількох рівнях: від розділення додатку на екрани до організації коду в межах одного класу. Activity або ViewController, який одночасно завантажує дані з мережі, парсить JSON та малює UI, порушує Separation of Concerns — такий код складно підтримувати, тестувати та розширювати. Альтернатива — винести кожен вид відповідальності в окремий компонент.

Принцип тісно пов'язаний з поняттям абстракції: кожен шар надає строго визначений інтерфейс та приховує деталі реалізації. Завдяки цьому розробник може замінити бібліотеку для роботи з мережею або базу даних, не переписуючи UI-логіку. Це особливо цінно в довгоживучих проектах, де вимоги та технології змінюються з часом.

Історія та походження принципу

Edsger Dijkstra вперше сформулював ідею Separation of Concerns у статті 1974 року «On the Role of Scientific Thought». Він стверджував, що складність програмних систем можна контролювати, розділяючи їх на частини, які аналізуються ізольовано. Цей підхід контрастував з монолітними програмами того часу, де код змішував обчислення, введення-виведення та користувацький інтерфейс.

У 1980-х ідею розвинули прихильники структурного програмування, а потім — об'єктно-орієнтованого підходу. Мови на кшталт Smalltalk та C++ надали механізми інкапсуляції та модульності, які зробили SoC практичним інструментом. Сучасні архітектурні патерни — MVC, MVP, MVVM та Clean Architecture — є прямим втіленням принципу Separation of Concerns.

У світі мобільної розробки Apple просувала MVC як стандарт для iOS, де Model-View-Controller розділяє дані, відображення та логіку керування. Google для Android запропонувала архітектурні рекомендації, засновані на ViewModel та Repository, — кожен компонент вирішує своє вузьке завдання. Без SoC мобільні додатки перетворюються на Massive View Controller — класи на тисячі рядків, де будь-яка зміна ризикує зламати всю функціональність.

Рівні розділення в мобільній архітектурі

Чотири основні шари утворюють типову архітектуру мобільного додатку, що реалізує Separation of Concerns. Кожен шар відповідає тільки за свою область та взаємодіє з сусідніми через інтерфейси.

UI-шар: View та ViewModel

View відповідає виключно за відображення даних та обробку користувацьких подій. В iOS це UIViewController та UIView, в Android — Fragment або Activity. ViewModel містить стан екрану та логіку перетворення даних у формат, готовий для відображення. Розділення гарантує, що заміна UIKit на SwiftUI або переписування екрану на Jetpack Compose не зачепить бізнес-логіку.

Тестування ViewModel не вимагає запуску емулятора або симулятора — достатньо модульних тестів, які перевіряють перетворення даних та реакцію на дії користувача. Це прямий наслідок Separation of Concerns: UI не змішується з бізнес-правилами, і кожен компонент тестується ізольовано.

Шар бізнес-логіки: Use Cases та Interactors

Use Case (або Interactor) містить бізнес-правила додатку — обчислення, перевірки, оркестрацію викликів до даних. Цей шар не знає про існування UI та фреймворків платформи. Use Case отримує дані з Repository, застосовує до них логіку та повертає готовий результат ViewModel. Розділення дозволяє перевикористовувати один Use Case на різних екранах.

Наприклад, LoginUseCase перевіряє валідність email, викликає AuthRepository для аутентифікації та повертає результат. Він не залежить від того, як виглядає екран логіну — SwiftUI, UIKit чи Compose. Якщо бізнес-правила змінюються, достатньо змінити один Use Case, не чіпаючи UI та базу даних.

Шар даних: Repository та DataSource

Repository абстрагує джерела даних: віддалений API, локальну базу даних або кеш у пам'яті. ViewModel та Use Case не знають, звідки саме надходять дані — Repository вирішує, завантажувати з мережі чи з кешу. Це розділення дозволяє змінювати реалізацію зберігання, не зачіпаючи бізнес-логіку та UI.

DataSource — ще більш низькорівневе розділення: NetworkDataSource відповідає тільки за HTTP-запити, LocalDataSource — за роботу з Room або CoreData. Repository комбінує виклики до різних DataSources в єдиний узгоджений інтерфейс. Кожен DataSource тестується незалежно за допомогою моків або фейкових серверів.

Правильна реалізація DataSource шару гарантує, що зміна схеми бази даних або заміна REST API на GraphQL зачепить тільки один DataSource, але не Repository та не його споживачів. Це прямий наслідок Separation of Concerns на рівні інфраструктури: кожна технічна concern ізольована та замінна без каскадних змін.

SoC у патернах проектування

MVVM (Model-View-ViewModel) — найпопулярніший патерн для мобільної розробки, що безпосередньо реалізує Separation of Concerns. Model містить дані та бізнес-логіку, View відповідає за відображення, а ViewModel зв'язує їх через реактивні механізми. У Flutter аналогічну роль виконує BLoC з розділенням на події, стани та бізнес-логіку.

Clean Architecture Роберта Мартіна (Uncle Bob) доводить SoC до максимуму: система ділиться на незалежні кільця — сутності, use cases, адаптери та фреймворки. Внутрішні кільця (сутності) не залежать від зовнішніх (фреймворків). Це дозволяє змінювати базу даних, UI-фреймворк і навіть платформу, не переписуючи core-логіку додатку.

На практиці мобільні проекти рідко реалізують повну Clean Architecture — для більшості додатків достатньо трьохшарової архітектури: UI, Domain та Data. Domain-шар містить Use Cases та бізнес-моделі і повністю ізольований від Android SDK або iOS SDK. Таке розділення дає 80% вигоди при 20% зусиль.

// Data layer — відповідає тільки за отримання даних
class UserRepository(private val api: UserApi) {
    suspend fun getUser(id: String): User = api.fetchUser(id)
}

// Domain layer — бізнес-логіка, не знає про API чи базу
class GetUserNameUseCase(
    private val repo: UserRepository
) {
    suspend fun invoke(id: String): String {
        val user = repo.getUser(id)
        return "${user.firstName} ${user.lastName}"
    }
}

// UI layer — тільки відображення
class UserViewModel(
    private val getUserName: GetUserNameUseCase
) {
    fun onUserLoaded(id: String) {
        viewModelScope.launch {
            _name.value = getUserName.invoke(id)
        }
    }
}

Код вище демонструє чисте розділення: UserRepository працює тільки з API, GetUserNameUseCase містить бізнес-логіку форматування імені, а UserViewModel керує станом UI. Кожен клас має одну причину для зміни, що і є суттю Separation of Concerns.

Переваги та обмеження Separation of Concerns

Основна перевага SoC — підтримуваність. Код, розділений на незалежні шари, простіше аналізувати: розробник дивиться тільки на шар, в якому відбувається помилка, і не відволікається на решту. В довгострокових проектах це скорочує час на пошук та виправлення багів на 30–50% порівняно з монолітним кодом.

Друга важлива перевага — тестованість. Коли бізнес-логіка ізольована від UI та фреймворків, вона покривається модульними тестами без запуску емулятора. Android та iOS проекти з високим покриттям Unit-тестів мають значно менше регресій при додаванні нових функцій.

Головне обмеження — зростання складності. Надмірне дроблення на мікрошари та абстракції веде до того, що для додавання простої кнопки розробник править п'ять файлів. Принцип Separation of Concerns вимагає розумного балансу: розділяти тільки ті області, які дійсно змінюються незалежно. Для маленьких проектів достатньо базового розділення на UI, логіку та дані без додаткових абстракцій.