Arhitectura și Pattern-urile în Dezvoltarea Mobile: Ce Sunt, Tipuri și Cum se Aplică

Principalele Pattern-uri Arhitecturale

Un pattern arhitectural determină modul în care responsabilitățile sunt distribuite între clasele aplicației. Alegerea pattern-ului afectează ușurința de a adăuga ecrane noi și de a testa codul.

MVC (Model-View-Controller)

MVC este un pattern clasic unde Model se ocupă de date, View de afișare, iar Controller de logică. În iOS, MVC este implicit (UIViewController); în Android, Activity. Dezavantajul este că Controller-ul devine adesea "masiv" (Massive View Controller). Conform unui sondaj al dezvoltatorilor iOS (Reddit, 2025), 62% consideră MVC principala cauză a codului ilizibil în proiecte vechi.

MVP (Model-View-Presenter)

MVP se diferențiază prin faptul că Presenter gestionează View-ul printr-o interfață, îmbunătățind testabilitatea. MVP a fost popular în Android înainte de Jetpack, dar este mai puțin convenabil decât MVVM.

MVVM (Model-View-ViewModel)

MVVM este pattern-ul recomandat de Google pentru Android și de Apple pentru iOS. ViewModel stochează starea, iar View se abonează la modificări prin Data Binding sau @Published. ViewModel nu depinde de View și este ușor de testat. La IT Sectr, folosim MVVM ca pattern principal în toate proiectele.

MVI și VIPER

MVI este un pattern reactiv unde fiecare acțiune urmează ciclul Intent → Model → View. MVI garantează o stare previzibilă. VIPER este un pattern iOS cu cinci straturi (View, Interactor, Presenter, Entity, Router), oferind izolare maximă, dar necesitând mult cod boilerplate.

Clean Architecture

Clean Architecture este conceptul lui Robert Martin care împarte o aplicație în straturi: straturile externe (UI, BD, rețea) depind de straturile interne (logică de afaceri, entități). În dezvoltarea mobile, Clean Architecture include trei straturi: data (repozitorii), domain (Use Cases) și presentation (ViewModels, UI).

Repository Pattern este o componentă cheie a Clean Architecture, care abstractizează sursa de date. Repozitoriul decide dacă să preia date din rețea sau din stocarea locală (Room, Core Data) și returnează un format unificat. Conform Google (Architecture Guide, 2025), Repository Pattern este recomandat pentru orice aplicație cu cereri de rețea. Clean Architecture este justificată în proiecte cu 3–5 ecrane sau mai multe — pentru aplicații simple, începeți cu MVVM.

Pattern-uri de Creare

Singleton

Singleton este un pattern arhitectural care garantează o singură instanță a unei clase și oferă un punct de acces global la aceasta. Este folosit pentru baze de date, manageri de setări și cache. În Kotlin, este creat prin object. Dezavantajul este că complică testarea din cauza stării globale.

Factory și Builder

Factory delegă crearea obiectelor unei metode de fabrică — în loc de new, apelezi fabrica. Builder este un pattern de construcție pas cu pas pentru obiecte complexe cu mulți parametri (AlertDialog.Builder, NotificationCompat.Builder). Builder îmbunătățește lizibilitatea și permite obiectelor să rămână imutabile după asamblare.

Pattern-uri Structurale și Comportamentale

Adapter, Facade, Delegate, Protocol

Adapter este un pattern arhitectural care convertește interfața unei clase într-o interfață așteptată de client. În Android, este RecyclerView.Adapter. Facade oferă o interfață simplificată unui sistem complex — de exemplu, o fațadă pentru o API care ascunde detaliile de autentificare. Delegate este un pattern iOS unde un obiect delegă o sarcină (UITableViewDelegate). Protocol este echivalentul unei interfețe în Swift.

Observer și Strategy

Observer este un pattern de abonare la schimbări: subiectul notifică abonații despre actualizări. În dezvoltarea mobile, Observer este baza LiveData, StateFlow, RxJava și Combine. Strategy este un pattern de algoritmi interschimbabili: conectezi o strategie diferită (sortare, validare) fără multiple instrucțiuni if-else.

Injecția Dependențelor și Gestionarea Stării

Dependency Injection este un pattern arhitectural unde un obiect primește dependențele din exterior în loc să le creeze singur. În loc de new Database(), transmiți baza de date prin constructor. DI simplifică testarea — poți folosi un Mock în locul unei baze de date reale — și facilitează schimbarea implementărilor. Framework-uri DI populare: Dagger și Hilt (Android), Swinject (iOS), Koin (Kotlin). Hilt — un wrapper peste Dagger recomandat de Google — reduce configurarea DI de 3 ori.

Service Locator este o alternativă la DI cu un registru central al dependențelor. Mai simplu de implementat, dar ascunde dependențele clasei, îngreunând testarea. Proiectele moderne preferă DI prin Hilt sau Koin.

Gestionarea Stării în Flutter

În Flutter, gestionarea stării este un ecosistem propriu. Redux — un singur Store cu modificări prin Actions → Reducer → State. BLoC de la Google separă evenimentele și stările prin Stream. Provider — un container DI simplu recomandat de Google pentru Flutter până în 2023. Riverpod — un Provider îmbunătățit care rezolvă problemele de compilare și testare. GetX — un micro-framework cu rutare, DI și gestionarea stării. Pentru dezvoltatorii Flutter începători, recomandăm Provider sau Riverpod ca cele mai bine documentate soluții.

Principii SOLID și DRY

Pe lângă pattern-urile specifice, există principii generale de proiectare arhitecturală aplicabile în orice limbaj și framework.

SOLID — cinci principii de proiectare orientată pe obiecte: Single Responsibility (o clasă — o sarcină), Open-Closed (deschis pentru extensie, închis pentru modificare), Liskov Substitution (subclasele înlocuiesc clasa părinte), Interface Segregation (interfețe mici), Dependency Inversion (dependență de abstracțiuni). În dezvoltarea mobile, SRP este cel mai util principiu: fiecare clasă face un singur lucru. Conform experienței IT Sectr, încălcarea SRP este cauza a 70% din problemele de testare în proiectele comerciale.

// Пример: нарушение SRP
class UserManager {
    fun saveUser(user: User) { /* сохранение */ }
    fun validateEmail(email: String): Boolean { /* валидация */ }
    fun sendEmail(user: User) { /* отправка */ }
    fun formatUser(user: User): String { /* форматирование */ }
}

// Исправление: разделяем на отдельные классы
class UserRepository { fun save(user: User) {} }
class EmailValidator { fun isValid(email: String): Boolean {} }
class EmailService { fun send(user: User) {} }
class UserFormatter { fun format(user: User): String {} }

Exemplul Kotlin arată cum transformăm o clasă UserManager cu patru responsabilități în patru clase cu câte o responsabilitate fiecare. Un astfel de cod este mai ușor de testat, modificat și reutilizat.

DRY (Don't Repeat Yourself) — evitați duplicarea codului. Extrageți logica repetată în metode sau clase partajate. KISS (Keep It Simple, Stupid) — simplitatea este mai importantă decât eleganța. YAGNI (You Aren't Gonna Need It) — nu scrieți cod pentru ceva ce poate nu va fi necesar. Aceste principii ajută la scrierea unui cod curat, întreținut fără redundanță.

Pattern-uri Platformă Android

ViewModel (Android) este o componentă arhitecturală Jetpack pentru stocarea stării UI, rezistentă la rotirea ecranului. ViewModel nu conține referințe la Activity și se curăță automat. LiveData — un container de date observabil cu conștientizare a ciclului de viață. StateFlow — un înlocuitor modern pentru LiveData bazat pe Kotlin Flow. SharedFlow — un Hot Flow pentru evenimente unice (navigare, toasturi).

Data Binding și Two-Way Binding — mecanisme de legare a UI și datelor în Android. Data Binding declară conexiunea în XML; Two-Way Binding actualizează automat câmpul în ViewModel. Unidirectional Data Flow — un principiu unde datele curg într-o singură direcție: State → UI → Event → State. La IT Sectr, folosim Unidirectional Data Flow în toate proiectele noi — reduce numărul de bug-uri cauzate de schimbări neașteptate de stare.