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 проверава исправност имејла, позива AuthRepository за аутентификацију и враћа резултат. Он не зависи од тога како изгледа екран за пријаву — SwiftUI, UIKit или Compose. Ако се пословна правила промене, довољно је изменити један Use Case, без дирања UI и базе података.

Слој података: Repository и DataSource

Repository апстрахује изворе података: удаљени API, локалну базу података или кеш у меморији. ViewModel и Use Case не знају одакле тачно долазе подаци — Repository одлучује да ли да учита из мреже или из кеша. Ово раздвајање омогућава промену имплементације складиштења без утицаја на пословну логику и UI.

DataSource је још нижи ниво раздвајања: NetworkDataSource одговара само за HTTP захтеве, LocalDataSource — за рад са Room или CoreData. Repository комбинује позиве ка различитим DataSource-има у јединствени конзистентни интерфејс. Сваки DataSource се тестира независно помоћу мокова или лажних сервера.

Правилна имплементација DataSource слоја гарантује да ће промена шеме базе података или замена REST API-ја GraphQL-ом утицати само на један DataSource, али не на Repository и његове потрошаче. Ово је директна последица Separation of Concerns на нивоу инфраструктуре: свака technical concern је изолована и замењива без каскадних промена.

SoC у обрасцима пројектовања

MVVM (Model-View-ViewModel) — најпопуларнији образац за мобилни развој, који директно имплементира Separation of Concerns. Model садржи податке и пословну логику, View одговара за приказ, а ViewModel их повезује путем реактивних механизама. У Flutter-у аналогну улогу има BLoC са раздвајањем на догађаје, стања и пословну логику.

Clean Architecture Роберта Мартина (Uncle Bob) доводи SoC до максимума: систем се дели на независне прстенове — ентитете, use cases, адаптере и фрејмворке. Унутрашњи прстенови (ентитети) не зависе од спољашњих (фрејмворка). Ово омогућава промену базе података, UI фрејмворка, па чак и платформе без преписивања основне логике апликације.

У пракси, мобилни пројекти ретко имплементирају потпуну Clean Architecture — за већину апликација довољна је трocлојна архитектура: 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 пројекти са високим покрићем модуларних тестова имају значајно мање регресија при додавању нових функција.

Главно ограничење — раст сложености. Прекомерно уситњавање на микрослојеве и апстракције води ка томе да за додавање једноставног дугмета програмер мења пет датотека. Принцип Separation of Concerns захтева разуман баланс: раздвајати само оне области које се стварно мењају независно. За мале пројекте довољно је основно раздвајање на UI, логику и податке без додатних апстракција.