Arhitektonski principi u mobilnom razvoju: šta su, koje vrste postoje i kako ih primeniti

SOLID principi

Arhitektonski principi — su temelj kvalitetnog koda. SOLID je akronim koji je uveo Robert Martin («Čika Bob») i opisuje pet principa objektno-orijentisanog dizajna. Praćenje SOLID-a čini kod fleksibilnijim, testabilnijim i otpornijim na promene. Kršenje arhitektonskih principa jedan je od glavnih uzroka tehničkog duga.

Razmotrimo svaki princip. Single Responsibility Principle (SRP) — svaka klasa treba da ima samo jedan razlog za promenu. Open/Closed Principle (OCP) — klase su otvorene za proširenje, ali zatvorene za modifikaciju. Liskov Substitution Principle (LSP) — objekti podtipova treba da zamene objekte osnovnog tipa bez narušavanja logike. Interface Segregation Principle (ISP) — mnogo specijalizovanih interfejsa je bolje od jednog opšteg. Dependency Inversion Principle (DIP) — zavisnost od apstrakcija, a ne od konkretnih implementacija.

Prema SonarQube analizi (2025), kršenje SOLID principa javlja se u 68% komercijalnih projekata. Najčešći problemi su kršenje SRP (35%) i ISP (22%). U IT Sectr-u, implementiramo SOLID u fazi arhitektonskog pregleda — ovo pomaže da se problemi identifikuju pre nego što prerastu u tehnički dug.

Single Responsibility Principle (SRP)

SRP (Princip jedinstvene odgovornosti) — najvažniji i istovremeno najčešće kršeni SOLID princip. Kaže: klasa treba da ima samo jedan razlog za promenu. Ako klasa radi previše, teško je testirati, menjadi i razumeti je.

Tipično kršenje je klasa koja istovremeno obrađuje podatke, čuva ih u bazi podataka i šalje e-mail obaveštenja. Primer ispod prikazuje kršenje SRP u Kotlin-u i kako ga popraviti.

// Kršenje SRP — klasa radi tri različite stvari
class UserService {
    fun registerUser(email: String, name: String) {
        // 1. Validacija podataka
        if (!email.contains("@")) throw IllegalArgumentException("Invalid email")
        
        // 2. Čuvanje u bazu
        val user = User(email, name)
        database.save(user)
        
        // 3. Slanje obaveštenja
        emailService.sendWelcomeEmail(email, name)
    }
}

// Popravka — podela u tri klase
class UserRegistrationService {
    fun register(email: String, name: String) {
        UserValidator().validate(email)
        val user = User(email, name)
        UserRepository().save(user)
        NotificationService().sendWelcome(user)
    }
}

U ispravljenoj verziji, svaka klasa je odgovorna za svoj zadatak: UserValidator — za validaciju, UserRepository — za čuvanje, NotificationService — za obaveštenja. Ovo čini kod testabilnim i višestruko upotrebljivim — možete zameniti implementaciju baze podataka bez menjanja logike validacije.

GRASP i Law of Demeter

GRASP (General Responsibility Assignment Software Patterns) — devet arhitektonskih principa raspodele odgovornosti između objekata, koje je opisao Craig Larman. Za razliku od SOLID-a, GRASP odgovara na pitanje «koja klasa treba da sadrži ovu metodu?». Ključni obrasci: Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, Protected Variations.

Law of Demeter (LoD, princip minimalne povezanosti) — jednostavno pravilo: objekat treba da komunicira samo sa neposrednim susedima. Ne treba pisati a.getB().getC().doSomething() — ovo stvara čvrstu povezanost između klasa. LoD poboljšava ponovnu upotrebu i pojednostavljuje testiranje.

U IT Sectr-u, proveravamo usklađenost sa LoD-om tokom pregleda koda. Ako metoda «prolazi» kroz tri ili više objekata, to je signal da arhitekturu treba pojednostaviti. Kršenje LoD-a je jedan od najčešćih Code Smell-ova u velikim projektima.

DRY / KISS / YAGNI

DRY (Don't Repeat Yourself), KISS (Keep It Simple, Stupid) i YAGNI (You Ain't Gonna Need It) — tri osnovna arhitektonska principa poznata svakom programeru. Uprkos svojoj jednostavnosti, kršenja se stalno dešavaju.

DRY — nemojte duplirati kod. Ako se ista logika pojavljuje na dva mesta, izdvojite je u zajedničku metodu ili klasu. Dupliranje je glavni izvor grešaka: ispravka na jednom mestu se zaboravi primeniti na drugom. DRY ne znači da ne možete imati sličan kod — važno je da se poslovna logika ne ponavlja.

KISS — što jednostavnije, to bolje. Složena rešenja sa mnogo apstrakcija i nasleđivanja su često preterana. Počnite sa jednostavnim rešenjem i usložnjavajte ga samo kada je potrebno. YAGNI — ne pišite kod za funkcionalnost koja bi mogla biti potrebna «jednog dana kasnije». Ovo dovodi do nadimanja baze koda i povećanja složenosti održavanja.

DRY — Don't Repeat Yourself

DRY — ne radi se samo o odsustvu kopiranja-nalepjivanja. To je princip prema kome svaki deo znanja ili logike treba da ima jedinstvenu, nedvosmislenu reprezentaciju u sistemu. Dupliranje može biti eksplicitno (kopiran kod) i implicitno (ista logika u različitim slojevima).

U IT Sectr-u, koristimo metrike analize koda za otkrivanje dupliranja. Alati poput SonarQube i Detekt pokazuju procenat dupliranog koda. Vrednost iznad 5% je razlog za refaktorisanje. Međutim, važno je zapamtiti: DRY ne treba postići po cenu pogrešnih apstrakcija — ponekad je bolje ostaviti dva slična dela koda kakvi jesu ako bi njihovo spajanje otežalo razumevanje.

Separation of Concerns i Modularnost

Separation of Concerns (SoC) — arhitektonski princip u kome se sistem deli na nezavisne delove (concerns), svaki rešava svoj zadatak. Klasičan primer je podela na slojeve: prezentacija, poslovna logika, pristup podacima. Svaki sloj zavisi samo od sloja ispod.

Modularnost — stepen u kome sistem može biti podeljen na module. Modul je logički povezana grupa klasa sa jasno definisanim interfejsom. Moduli treba da budu labavo povezani (low coupling) i snažno kohezivni (high cohesion).

Kohezija vs Povezanost

Kohezija (Cohesion) — mera koliko su elementi unutar jednog modula povezani jedni sa drugima. Visoka kohezija je dobra: klasa radi jednu stvar i radi je dobro. Niska povezanost (Low coupling) — mera koliko su moduli nezavisni jedni od drugih. Niska povezanost je dobra: promena jednog modula ne lomi druge.

Idealna arhitektura je visoka kohezija i niska povezanost. U praksi, ovo znači: klasa sadrži metode koje rade na istim podacima (kohezija) i zavisi samo od apstrakcija, a ne od konkretnih implementacija (povezanost). Neravnoteža dovodi do «Božanskih objekata» ili «špageti koda».

Tehnički dug i Code Smell

Tehnički dug (Technical Debt) — metafora koju je uveo Ward Cunningham koja opisuje «kamatu» koju tim plaća za suboptimalne arhitektonske odluke i kršenje arhitektonskih principa. Kao i finansijski dug, tehnički dug može biti nameran (odlučili smo da uradimo brzo, preraditi ćemo kasnije) i nenameran (loša arhitektura zbog nedostatka iskustva).

Code Smell — površinski znaci dubokih problema u kodu. Termin je popularizovao Martin Fowler u knjizi «Refactoring». Tipični Code Smell-ovi: dugačke metode, velike klase, dugački lanci poziva, dupliranje koda, prekomerna upotreba komentara (umesto jasnog koda).

U IT Sectr-u, tehnički dug se prati u Jira-i kao odvojeni zadaci. Svaki sprint izdvajamo 20% vremena za refaktorisanje i otplatu duga. Sistematski rad sa tehničkim dugom je jedini način da se izbegne situacija u kojoj dodavanje nove funkcije traje duže od njenog razvoja od nule.