Arhitektura i obrasci u mobilnom razvoju: šta su, koje vrste postoje i kako primeniti

Glavni arhitektonski obrasci

Arhitektonski obrazac određuje kako se odgovornosti raspoređuju između klasa aplikacije. Izbor obrasca utiče na lakoću dodavanja novih ekrana i testiranja koda.

MVC (Model-View-Controller)

MVC je klasičan obrazac gde Model upravlja podacima, View prikazom, a Controller logikom. U iOS-u, MVC je podrazumevani (UIViewController); u Android-u, Activity. Nedostatak je što Controller često postaje "masivan" (Massive View Controller). Prema anketi iOS programera (Reddit, 2025), njih 62% navodi MVC kao glavni uzrok nečitljivog koda u starim projektima.

MVP (Model-View-Presenter)

MVP se razlikuje po tome što Presenter upravlja View-om putem interfejsa, poboljšavajući testabilnost. MVP je bio popularan u Android-u pre Jetpack-a, ali zaostaje za MVVM-om po udobnosti.

MVVM (Model-View-ViewModel)

MVVM je preporučeni obrazac od strane Google za Android i Apple za iOS. ViewModel čuva stanje, a View se pretplaćuje na promene putem Data Binding ili @Published. ViewModel ne zavisi od View-a i lako se testira. U IT Sectr-u koristimo MVVM kao glavni obrazac u svim projektima.

MVI i VIPER

MVI je reaktivni obrazac gde svaka akcija prati ciklus Intent → Model → View. MVI garantuje predvidljivo stanje. VIPER je iOS obrazac sa pet slojeva (View, Interactor, Presenter, Entity, Router), koji pruža maksimalnu izolaciju, ali zahteva mnogo šablonskog koda.

Clean Architecture

Clean Architecture je koncept Roberta Martina koji deli aplikaciju na slojeve: spoljašnji slojevi (UI, baza podataka, mreža) zavise od unutrašnjih (poslovna logika, entiteti). U mobilnom razvoju, Clean Architecture uključuje tri sloja: data (repozitorijumi), domain (Use Cases) i presentation (ViewModels, UI).

Repository Pattern je ključna komponenta Clean Architecture, koja apstrahuje izvor podataka. Repozitorijum odlučuje da li će preuzeti podatke iz mreže ili lokalnog skladišta (Room, Core Data) i vraća jedinstveni format. Prema Google-u (Architecture Guide, 2025), Repository Pattern se preporučuje za svaku aplikaciju sa mrežnim zahtevima. Clean Architecture je opravdana u projektima od 3–5 ekrana — za jednostavne aplikacije počnite sa MVVM.

Obrasci kreiranja

Singleton

Singleton je arhitektonski obrazac koji garantuje jedinstvenu instancu klase i pruža globalnu tačku pristupa njoj. Koristi se za baze podataka, menadžere podešavanja i keš memoriju. U Kotlin-u se kreira putem object. Nedostatak je što komplikuje testiranje zbog globalnog stanja.

Factory i Builder

Factory delegira kreiranje objekata fabričkom metodu — umesto new, pozivate fabriku. Builder je obrazac postepenog konstruisanja složenih objekata sa mnogo parametara (AlertDialog.Builder, NotificationCompat.Builder). Builder poboljšava čitljivost i omogućava objektima da ostanu nepromenljivi nakon sklapanja.

Strukturni i bihejvioralni obrasci

Adapter, Facade, Delegate, Protocol

Adapter je arhitektonski obrazac koji pretvara interfejs jedne klase u interfejs koji klijent očekuje. U Android-u, to je RecyclerView.Adapter. Facade pruža pojednostavljeni interfejs složenom sistemu — na primer, fasada za API koja skriva detalje autentifikacije. Delegate je iOS obrazac gde objekat delegira zadatak (UITableViewDelegate). Protocol je pandan interfejsu u Swift-u.

Observer i Strategy

Observer je obrazac pretplate na promene: subjekt obaveštava pretplatnike o ažuriranjima. U mobilnom razvoju, Observer je osnova LiveData, StateFlow, RxJava i Combine. Strategy je obrazac zamenjivih algoritama: priključujete različitu strategiju (sortiranje, validacija) bez višestrukih if-else naredbi.

Injektovanje zavisnosti i upravljanje stanjem

Dependency Injection je arhitektonski obrazac gde objekat prima svoje zavisnosti spolja umesto da ih sam kreira. Umesto new Database(), prosleđujete bazu podataka kroz konstruktor. DI pojednostavljuje testiranje — možete koristiti Mock umesto prave baze podataka — i olakšava zamenu implementacija. Popularni DI frejmvorci: Dagger i Hilt (Android), Swinject (iOS), Koin (Kotlin). Hilt — omotač oko Dagger-a koji preporučuje Google — smanjuje podešavanje DI za 3 puta.

Service Locator je alternativa DI-ju sa centralnim registrom zavisnosti. Jednostavniji za implementaciju, ali skriva zavisnosti klase, otežavajući testiranje. Moderni projekti preferiraju DI putem Hilt-a ili Koin-a.

Upravljanje stanjem u Flutter-u

U Flutter-u, upravljanje stanjem je poseban ekosistem. Redux — jedinstveni Store sa promenama kroz Actions → Reducer → State. Google-ov BLoC razdvaja događaje i stanja kroz Stream. Provider — jednostavan DI kontejner koji Google preporučuje za Flutter do 2023. Riverpod — poboljšani Provider koji rešava probleme sa kompilacijom i testiranjem. GetX — mikro-frejmvork sa rutiranjem, DI i upravljanjem stanjem. Za početnike u Flutter-u preporučujemo Provider ili Riverpod kao najbolje dokumentovana rešenja.

SOLID i DRY principi

Pored specifičnih obrazaca, postoje opšti principi arhitektonskog dizajna koji su primenljivi u bilo kom jeziku i frejmvorku.

SOLID — pet principa objektno-orijentisanog dizajna: Single Responsibility (jedna klasa — jedan zadatak), Open-Closed (otvorena za proširenje, zatvorena za izmenu), Liskov Substitution (podklase zamenjuju nadklasu), Interface Segregation (mali interfejsi), Dependency Inversion (zavisnost od apstrakcija). U mobilnom razvoju, SRP je najkorisniji princip: svaka klasa radi samo jednu stvar. Prema iskustvu IT Sectr-a, kršenje SRP-a je uzrok 70% problema sa testiranjem u komercijalnim projektima.

// Пример: нарушение 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 {} }

Primer u Kotlin-u pokazuje kako od jedne UserManager klase sa četiri odgovornosti dobijamo četiri klase sa po jednom odgovornošću. Takav kod je lakše testirati, menjati i ponovo koristiti.

DRY (Don't Repeat Yourself) — izbegavajte dupliranje koda. Izdvajajte ponavljajuću logiku u zajedničke metode ili klase. KISS (Keep It Simple, Stupid) — jednostavnost je važnija od elegancije. YAGNI (You Aren't Gonna Need It) — ne pišite kod za nešto što možda neće biti potrebno. Ovi principi pomažu u pisanju čistog, održivog koda bez suvišnosti.

Platformski obrasci Android

ViewModel (Android) je Jetpack arhitektonska komponenta za čuvanje UI stanja, otporna na rotaciju ekrana. ViewModel ne sadrži reference na Activity i automatski se čisti. LiveData — posmatrački kontejner podataka sa svešću o životnom ciklusu. StateFlow — moderna zamena za LiveData zasnovana na Kotlin Flow. SharedFlow — Hot Flow za jednokratne događaje (navigacija, tostovi).

Data Binding i Two-Way Binding — mehanizmi za povezivanje UI i podataka u Android-u. Data Binding deklariše vezu u XML-u; Two-Way Binding automatski ažurira polje u ViewModel-u. Unidirectional Data Flow — princip gde podaci teku u jednom smeru: State → UI → Event → State. U IT Sectr-u koristimo Unidirectional Data Flow u svim novim projektima — smanjuje broj bagova uzrokovanih neočekivanim promenama stanja.