SoC в мобилното разработване: какво е, принципи и разделение на отговорностите

Какво означава съкращението SoC

SoC означава Separation of Concerns — «разделение на отговорностите» или «разделяне на областите на интерес». В контекста на програмирането, терминът concern обозначава всяка отделима функционалност: показване на потребителски интерфейс, обработка на кликвания, валидиране на данни, мрежова комуникация или работа с база данни. Принципът SoC предписва групиране на кода около тези области, така че промените в една да не засягат другите.

Съкращението SoC се използва широко в техническата литература, архитектурни дискусии и документация на frameworks. Например в документацията на Android Architecture Components многократно се споменава SoC като мотивация за разделяне на ViewModel и View. В iOS общността терминът се използва при обсъждане на проблема Massive View Controller — пряко следствие от липсата на SoC.

Важно е да се разбере, че SoC не е еднократно действие, а непрекъснат процес. С разрастването на приложението се появяват нови области на отговорност и архитектурата трябва да се преразглежда. Добрата кодова база преминава през няколко итерации на разделяне, преди да достигне стабилно състояние, в което всеки concern е изолиран и управляем.

SoC срещу Separation of Concerns

Separation of Concerns и съкращението му SoC обозначават един и същ принцип. Разликата е само в контекста на използване: пълното име се използва в официални документи, учебни материали и при първото обяснение на концепцията на нови разработчици. SoC е удобен в технически дискусии, code review и документация, където краткостта е важна.

В професионалната среда и двата термина са взаимозаменяеми. Разработчикът може да каже «тук SoC е нарушен» или «това нарушава Separation of Concerns» — смисълът не се променя. В обявите за работа и архитектурните изисквания обаче по-често се среща пълното име, докато в чатовете и code review — съкращението. Познаването на двата варианта е необходимо за комфортно навлизане в индустрията.

Съществува терминологично объркване: съкращението SoC се използва също в хардуерен контекст за System-on-a-Chip (система на чип). В мобилното разработване контекстът винаги е ясен от обкръжението — ако дискусията касае архитектурата на кода, става въпрос за Separation of Concerns. В тази статия SoC навсякъде се отнася до принципа на разделение на отговорностите.

Как SoC се прилага в мобилната архитектура

Трислойна архитектура — най-честият начин за реализация на SoC в мобилни приложения. Тя разделя кода на Presentation (UI), Domain (бизнес логика) и Data (работа с източници). Всеки слой съдържа строго определени типове класове и е изолиран от съседите чрез интерфейси. Този подход е еднакво ефективен за iOS, Android и Flutter проекти.

Presentation слой и ViewModel

View и ViewModel образуват презентационния слой. View отговаря за изобразяването на интерфейса и предаването на потребителски събития. ViewModel съхранява състоянието на екрана и преобразува данните от Domain слоя във формат, готов за показване. ViewModel няма референции към Activity, Fragment или UIViewController — това осигурява SoC между UI и логиката.

Например в Android Jetpack ViewModel оцелява при завъртане на екрана, докато UI се пресъздава. Без SoC ще трябва да съхраняваме състоянието в Activity, смесвайки управлението на жизнения цикъл с данни. ViewModel решава тази задача изолирано, демонстрирайки чиста реализация на принципа за разделение на отговорностите.

Domain слой и Use Cases

Use Cases съдържат бизнес правила, независими от платформата. Този слой не импортира Android SDK, iOS UIKit или Flutter framework. Use Case получава данни от Repository, прилага към тях бизнес логика и връща резултата. Благодарение на SoC, един Use Case може да се преизползва на различни екрани и платформи.

Класически пример — ValidateAndSaveUseCase за регистрационен формуляр. Той проверява коректността на имейл и парола, извиква UserRepository за запазване и връща ValidationResult. Нито UI, нито базата данни знаят за правилата за валидация — те са концентрирани на едно място, което опростява тяхната промяна.

Data слой и Repository

Repository абстрахира източниците на данни от останалата част на приложението. ViewModel не знае откъде идват данните — REST API, GraphQL, локална база данни или кеш. Repository решава кой източник да използва и скрива тази логика зад интерфейс. Това е SoC между получаването на данни и тяхното потребление.

DataSource осигурява още по-дълбоко разделение: RemoteDataSource отговаря само за HTTP заявки, LocalDataSource — за работа с Room, CoreData или SharedPreferences. Repository ги комбинира, прилагайки стратегии за кеширане. Всеки DataSource може да бъде заменен независимо, което е критично при миграция между сървъри или бази данни.

Такава многостепенна система DataSource реализира SoC на инфраструктурно ниво: мрежова комуникация, локално съхранение и кеширане — отделни concerns, всеки със своя логика и жизнен цикъл. При смяна на HTTP клиента се променя само RemoteDataSource, а Repository и по-горните слоеве остават незасегнати, което потвърждава практическата стойност на разделението на отговорностите.

SoC в архитектурните модели

MVP (Model-View-Presenter) — един от първите модели, които изрично реализират SoC в мобилното разработване. Presenter съдържа логиката и управлява View чрез интерфейс. View е пасивен — показва само това, което казва Presenter. Разделението опростява тестването: Presenter се тества без емулатор, а View остава толкова прост, че няма какво да се счупи.

MVVM добави реактивно свързване: View се абонира за промените на ViewModel чрез Observable или StateFlow. ViewModel не съхранява референция към View, което елиминира риска от изтичане на памет и още по-силно разделя concerns. В Android MVVM стана стандарт благодарение на Jetpack ViewModel и LiveData, в iOS — благодарение на Combine и RxSwift.

Clean Architecture на Robert Martin довежда SoC до радикално разделение на пръстени. Външният пръстен (frameworks и драйвери) зависи от вътрешния (entities), но не и обратното. На практика мобилните проекти рядко реализират и четирите пръстена — слоевете Domain и Data около Presentation са достатъчни. Но самият принцип на зависимост «навътре» дава значителни предимства при смяна на frameworks.

// View — само показване, без логика
final class LoginViewController: UIViewController {
    let viewModel: LoginViewModel

    func loginTapped() {
        viewModel.login(emailField.text, passwordField.text)
    }
}

// ViewModel — съдържа логиката на екрана, не знае UIKit
final class LoginViewModel {
    private let loginUseCase: LoginUseCase

    func login(email: String?, password: String?) {
        loginUseCase.execute(email, password)
    }
}

// Use Case — бизнес логика, независима от платформата
final class LoginUseCase {
    private let repo: AuthRepository

    func execute(email: String?, password: String?) {
        guard let e = email, let p = password else { return }
        repo.authenticate(e, p)
    }
}

Примерът показва три нива на SoC: LoginViewController само предава събития, LoginViewModel управлява състоянието, LoginUseCase съдържа бизнес правила. Всеки клас се тества независимо и смяната на UI framework не засяга Use Case.

Типични нарушения на SoC в мобилни проекти

Massive View Controller — най-честото нарушение на SoC в iOS. Клас, който управлява UI, обработва мрежови заявки, парсва JSON и съхранява данни, нарушава принципа на всички нива. Решение — изваждане на всяка отговорност в отделен компонент: NetworkingService, JSONParser, CoreDataStack, оставяйки на ViewController само управлението на View.

В Android аналогичен проблем — God Activity или God Fragment. Една активност, която зарежда данни, валидира форми, показва диалози и обновява UI. Лекува се с въвеждане на ViewModel и Repository, които поемат управлението на състоянието и данните. ViewModel също така предпазва от загуба на данни при завъртане на екрана.

Третото нарушение — смесване на платформен и бизнес код. Например поставяне на HTTP заявка директно в SwiftUI View или Android Composable. Това прави кода непреносим и труден за тестване. Правилният подход — изваждане на заявката в Repository, който се извиква чрез Use Case, а View само се абонира за резултата. Всеки елемент на системата решава своята задача и не излиза извън границите си.