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

Шта значи скраћеница SoC

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

Скраћеница SoC се широко користи у техничкој литератури, архитектонским дискусијама и документацији оквира. На пример, у документацији Android Architecture Components више пута се помиње SoC као мотивација за раздвајање ViewModel и View. У iOS заједници термин се користи при расправи о проблему Massive View Controller — директне последице недостатка SoC.

Важно је разумети да SoC није једнократна акција, већ континуирани процес. Како апликација расте, појављују се нове области одговорности и архитектура се мора преиспитивати. Добра кодна база пролази кроз неколико итерација поделе пре него што достигне стабилно стање где је сваки concern изолован и управљив.

SoC vs 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 Роберта Мартина доводи SoC до радикалне поделе на прстенове. Спољни прстен (оквири и драјвери) зависи од унутрашњег (ентитета), али не обрнуто. У пракси, мобилни пројекти ретко реализују сва четири прстена — довољни су Domain и Data слојеви око Presentation. Али сам принцип зависности «ка унутра» даје значајне предности при промени оквира.

// 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 оквира не утиче на 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 само претплаћује на резултат. Сваки елемент система решава свој задатак и не излази из својих граница.