Separation of Concerns în dezvoltarea mobilă — ce este, principii și aplicare

Ce este Separation of Concerns

Separation of Concerns este principiul de descompunere a unui sistem software în părți independente, fiecare rezolvând o singură sarcină. Termenul concern (domeniu de responsabilitate) desemnează orice parte separabilă a funcționalității: afișarea ecranului, procesarea click-ului, validarea datelor sau comunicarea în rețea. Principiul prescrie gruparea codului astfel încât modificările într-un domeniu să nu necesite modificări în altele.

În dezvoltarea mobilă SoC se manifestă la mai multe niveluri: de la împărțirea aplicației în ecrane până la organizarea codului în interiorul unei singure clase. O Activity sau un ViewController care încarcă simultan date din rețea, parsează JSON și desenează UI încalcă Separation of Concerns — un astfel de cod este greu de întreținut, testat și extins. Alternativa — mutarea fiecărui tip de responsabilitate într-o componentă separată.

Principiul este strâns legat de conceptul de abstractizare: fiecare strat oferă o interfață strict definită și ascunde detaliile de implementare. Datorită acestui fapt, dezvoltatorul poate înlocui biblioteca de rețea sau baza de date fără a rescrie logica UI. Acest lucru este deosebit de valoros în proiecte de lungă durată, unde cerințele și tehnologiile se schimbă în timp.

Istoria și originea principiului

Edsger Dijkstra a formulat pentru prima dată ideea Separation of Concerns într-un articol din 1974 «On the Role of Scientific Thought». El a susținut că complexitatea sistemelor software poate fi controlată prin împărțirea lor în părți care sunt analizate izolat. Această abordare contrasta cu programele monolitice ale vremii, unde codul amesteca calculele, intrarea-ieșirea și interfața cu utilizatorul.

În anii 1980, ideea a fost dezvoltată de susținătorii programării structurate, apoi ai abordării orientate pe obiecte. Limbaje precum Smalltalk și C++ au oferit mecanisme de încapsulare și modularitate care au transformat SoC într-un instrument practic. Modelele arhitecturale moderne — MVC, MVP, MVVM și Clean Architecture — sunt o întruchipare directă a principiului Separation of Concerns.

În lumea dezvoltării mobile, Apple a promovat MVC ca standard pentru iOS, unde Model-View-Controller separă datele, afișarea și logica de control. Google pentru Android a oferit recomandări arhitecturale bazate pe ViewModel și Repository — fiecare componentă își rezolvă sarcina specializată. Fără SoC, aplicațiile mobile se transformă în Massive View Controller — clase cu mii de linii, unde orice modificare riscă să strice întreaga funcționalitate.

Niveluri de separare în arhitectura mobilă

Patru straturi principale formează arhitectura tipică a unei aplicații mobile care implementează Separation of Concerns. Fiecare strat răspunde doar pentru domeniul său și interacționează cu cele vecine prin interfețe.

Stratul UI: View și ViewModel

View răspunde exclusiv pentru afișarea datelor și procesarea evenimentelor utilizatorului. În iOS este UIViewController și UIView, în Android — Fragment sau Activity. ViewModel conține starea ecranului și logica de transformare a datelor într-un format gata de afișare. Separarea garantează că înlocuirea UIKit cu SwiftUI sau rescrierea ecranului în Jetpack Compose nu va afecta logica de afaceri.

Testarea ViewModel-ului nu necesită pornirea emulatorului sau simulatorului — sunt suficiente testele unitare care verifică transformarea datelor și reacția la acțiunile utilizatorului. Aceasta este o consecință directă a Separation of Concerns: UI nu se amestecă cu regulile de afaceri, iar fiecare componentă este testată izolat.

Stratul logicii de afaceri: Use Cases și Interactors

Use Case (sau Interactor) conține regulile de afaceri ale aplicației — calcule, validări, orchestrarea apelurilor către date. Acest strat nu știe de existența UI și a framework-urilor platformei. Use Case primește date de la Repository, aplică logica și returnează rezultatul gata către ViewModel. Separarea permite reutilizarea unui Use Case pe ecrane diferite.

De exemplu, LoginUseCase verifică validitatea emailului, apelează AuthRepository pentru autentificare și returnează rezultatul. Nu depinde de cum arată ecranul de autentificare — SwiftUI, UIKit sau Compose. Dacă regulile de afaceri se schimbă, este suficient să modificați un Use Case, fără a atinge UI și baza de date.

Stratul de date: Repository și DataSource

Repository abstrage sursele de date: API-ul la distanță, baza de date locală sau memoria cache. ViewModel și Use Case nu știu exact de unde provin datele — Repository decide dacă încarcă din rețea sau din cache. Această separare permite schimbarea implementării stocării fără a afecta logica de afaceri și UI.

DataSource este o separare de nivel inferior: NetworkDataSource răspunde doar pentru cererile HTTP, LocalDataSource — pentru lucrul cu Room sau CoreData. Repository combină apelurile către diferite DataSource-uri într-o interfață unitară coerentă. Fiecare DataSource este testat independent cu ajutorul mock-urilor sau serverelor simulate.

Implementarea corectă a stratului DataSource garantează că modificarea schemei bazei de date sau înlocuirea REST API cu GraphQL va afecta doar un DataSource, dar nu Repository și consumatorii săi. Aceasta este o consecință directă a Separation of Concerns la nivel de infrastructură: fiecare technical concern este izolat și înlocuibil fără modificări în cascadă.

SoC în modelele de proiectare

MVVM (Model-View-ViewModel) — cel mai popular model pentru dezvoltarea mobilă, care implementează direct Separation of Concerns. Model conține datele și logica de afaceri, View răspunde pentru afișare, iar ViewModel le leagă prin mecanisme reactive. În Flutter, un rol similar îl joacă BLoC cu separarea în evenimente, stări și logică de afaceri.

Clean Architecture a lui Robert Martin (Uncle Bob) duce SoC la maximum: sistemul este împărțit în inele independente — entități, use cases, adaptoare și framework-uri. Inelele interioare (entitățile) nu depind de cele exterioare (framework-uri). Acest lucru permite schimbarea bazei de date, a framework-ului UI și chiar a platformei fără a rescrie logica de bază a aplicației.

În practică, proiectele mobile rareori implementează Clean Architecture completă — pentru majoritatea aplicațiilor este suficientă arhitectura trei straturi: UI, Domain și Data. Stratul Domain conține Use Cases și modelele de afaceri și este complet izolat de Android SDK sau iOS SDK. O astfel de separare oferă 80% din beneficii cu 20% din efort.

// Data layer — răspunde doar pentru obținerea datelor
class UserRepository(private val api: UserApi) {
    suspend fun getUser(id: String): User = api.fetchUser(id)
}

// Domain layer — logica de afaceri, nu știe de API sau bază de date
class GetUserNameUseCase(
    private val repo: UserRepository
) {
    suspend fun invoke(id: String): String {
        val user = repo.getUser(id)
        return "${user.firstName} ${user.lastName}"
    }
}

// UI layer — doar afișare
class UserViewModel(
    private val getUserName: GetUserNameUseCase
) {
    fun onUserLoaded(id: String) {
        viewModelScope.launch {
            _name.value = getUserName.invoke(id)
        }
    }
}

Codul de mai sus demonstrează separarea pură: UserRepository lucrează doar cu API, GetUserNameUseCase conține logica de afaceri de formatare a numelui, iar UserViewModel gestionează starea UI. Fiecare clasă are un motiv unic de modificare, ceea ce este esența Separation of Concerns.

Avantaje și limitări ale Separation of Concerns

Principalul avantaj al SoC — mentenabilitatea. Codul împărțit în straturi independente este mai ușor de analizat: dezvoltatorul se uită doar la stratul în care apare eroarea și nu se distrage cu celelalte. În proiectele pe termen lung, aceasta reduce timpul de căutare și remediere a erorilor cu 30–50% comparativ cu codul monolitic.

Al doilea avantaj important — testabilitatea. Când logica de afaceri este izolată de UI și framework-uri, este acoperită de teste unitare fără a porni emulatorul. Proiectele Android și iOS cu acoperire ridicată a testelor unitare au semnificativ mai puține regresii la adăugarea de funcționalități noi.

Limitarea principală — creșterea complexității. Fragmentarea excesivă în micro-straturi și abstractizări duce la situația în care pentru a adăuga un simplu buton, dezvoltatorul modifică cinci fișiere. Principiul Separation of Concerns necesită un echilibru rezonabil: separați doar acele domenii care se schimbă cu adevărat independent. Pentru proiecte mici, este suficientă separarea de bază în UI, logică și date fără abstractizări suplimentare.