Спојеност (Coupling) у мобилном развоју — кључни појмови, типови и како је смањити

Шта је Coupling

Coupling (спојеност) је метрика која одређује колико је један модул или класа повезан са другим. Што више један модул зна о унутрашњој структури другог, већи је coupling и теже је мењати систем. У добро пројектованој архитектури, coupling треба да буде минималан — модули комуницирају само кроз строго дефинисане интерфејсе.

Разликују се две стране coupling-а: afferent (долазне зависности — колико модула зависи од датог) и efferent (одлазне зависности — од колико модула зависи дати). Анализа ових метрика омогућава идентификацију „врућих тачака" у архитектури, где ће промена једног модула утицати на многе друге. Алати попут IntelliJ Dependency Analyzer и Xcode Graph визуализују ове везе.

Важно је разумети да нулти coupling није могућ — модули морају некако да комуницирају, иначе то није систем, већ скуп изолованих програма. Задатак архитекте је да coupling учини управљивим и транспарентним. Идеал: модули комуницирају само кроз интерфејсе и преносе само једноставне податке, не знајући о унутрашњој структури једни других. То се назива loose coupling (слаба спојеност).

Типови спојености од слабе до јаке

Шест типова coupling-а чини скалу од најбољег до најгорег. Разумевање ове скале помаже у процени постојећег кода и одабиру правца рефакторисања. Већина мобилних пројеката има мешовите типове coupling-а, а задатак архитекте је да постепено замењује јаке типове слабима.

Data coupling — најбољи тип

Data coupling (спојеност по подацима) — модули размењују само једноставне податке кроз параметре метода. Модул А позива метод модула B, прослеђујући примитиве или једноставне структуре, и добија резултат. Модул А не зна како је B имплементиран изнутра. Ово је најпожељнији тип coupling-а: минимизира последице промена.

Пример: EmailValidator.isValid(email: String): Boolean. Класа-потрошач прослеђује стринг и добија Boolean, без знања о регуларним изразима или правилима валидације унутар validator-а. Промена логике валидације не захтева промену потрошача — coupling је минималан. Data coupling је циљ за све јавне интерфејсе у апликацији.

Stamp coupling — прихватљив, али не и идеалан

Stamp coupling (спојеност по структури) — модули размењују сложене објекте, али користе само део њихових поља. Модул А прослеђује објекат User методи calculateDiscount, која користи само user.status. Проблем: ако се структура User промени (дода се обавезно поље), модул calculateDiscount се неће променити, али потрошач који креира објекат User — хоће.

У пракси, stamp coupling је неизбежан и прихватљив ако је прослеђени објекат стандардни модел података (Entity). Проблем настаје када модул добија цео објекат само ради једног поља. У таквим случајевима боље је проследити конкретну вредност директно (data coupling). Решење — анализирати коришћење поља од стране примаоца.

Control, External, Common и Content coupling

Control coupling — један модул прослеђује другом флег који контролише његово понашање (calculate(useNewAlgorithm: Boolean)). Ово је горе од stamp coupling-а, јер потрошач мора да зна унутрашње варијанте рада позваног модула. Решење: поделити метод на два — calculateWithNewAlgorithm() и calculateWithLegacyAlgorithm().

External coupling — модули зависе од спољног протокола, формата података или API-ја. Сви модули који парсирају исти JSON или раде са истом базом података имају external coupling. Потпуно га избећи није могуће, али се може изоловати: креирање слоја мапирања између спољног формата и унутрашњих модела. Common coupling — модули деле заједничко глобално стање. Content coupling — најгори тип, када модул директно мења унутрашње податке другог модула.

Скала coupling-а од data (идеал) до content (катастрофа) — практичан алат за код-преглед. Ако видите у пројекту common или content coupling — то је приоритетни циљ рефакторисања. Data и stamp coupling су прихватљиви и присутни у сваком пројекту, али њихов број треба контролисати.

Зашто је coupling критичан у мобилном развоју

Висок coupling претвара развој у успорен процес, где свака промена захтева проверу десетина потенцијално покварених модула. У мобилном развоју ово је посебно критично: платформе се ажурирају годишње (Android API Level, iOS SDK), библиотеке — квартално, а пословни захтеви — непрекидно. Слаба спојеност је једини начин да се носи са овим током промена без сталних регресија.

Пример из праксе: мобилна апликација где сви екрани директно импортују NetworkingManager и DatabaseManager. При замени HTTP клијента са Retrofit на Ktor (Android) или са URLSession на Alamofire (iOS), програмер би морао да исправи сваки екран. При ниском coupling-у довољно је променити једну имплементацију скривену иза интерфејса NetworkDataSource — потрошачи неће приметити замену.

Утицај coupling-а на јединичне тестове је такође огроман. Класа са високим coupling-ом (директно креирање зависности кроз конструктор) не може се тестирати изоловано — вуче за собом базу података, мрежу и UI. За тестирање такве класе мора се покренути емулатор и чекати интеграциони тестови. Класа са ниским coupling-ом прима зависности кроз constructor injection и лако се мокира.

// Висок coupling — класа сама ствара своје зависности
class ProfileViewModelHigh {
    private val api = RetrofitApi()
    private val db = RoomDatabase.getInstance()
    private val cache = MemoryCache()
}

// Низак coupling — зависности се преносе кроз конструктор
class ProfileViewModelLow(
    private val api: ApiService,
    private val db: DatabaseService,
    private val cache: CacheService
)

У првом случају, ProfileViewModelHigh је чврсто везан за конкретне имплементације — замена Retrofit-а са Ktor захтева промену кода ViewModel-а. У другом случају, ProfileViewModelLow зависи само од интерфејса, чије се имплементације достављају споља. Тестирање друге класе је тривијално: прослеђујемо мок-имплементације и проверавамо логику без емулатора.

Обрасци за смањење coupling-а

Dependency Inversion Principle (D у SOLID) — основа за смањење coupling-а. Принцип налаже да зависимо од апстракција, а не од конкретних имплементација. Уместо да класа директно креира објекат RetrofitApi, треба да прими интерфејс ApiService. Ово помера везу са конкретне библиотеке на ниво апстракције, која се може заменити без промене потрошача.

Observer pattern (или његове реактивне верзије — StateFlow, Combine Publishers) смањује coupling између извора података и претплатника. Претплатник не зна одакле долазе подаци — он само реагује на промене. Ово раздваја пошиљаоца и примаоца: може се додати нови извор података без промене постојећих претплатника. EventBus и SharedFlow раде по истом принципу.

Bridge pattern раздваја апстракцију и имплементацију, омогућавајући им да се мењају независно. У мобилном развоју Bridge се примењује, на пример, за модуле зависне од платформе: заједнички интерфејс ImageLoader са различитим имплементацијама за iOS (Kingfisher, Nuke) и Android (Glide, Coil). Код који ради са ImageLoader-ом не зависи од изабране библиотеке и може је заменити једноставном променом имплементације.

Dependency Injection као алат за управљање coupling-ом

Dependency Injection (DI) — најпрактичнији алат за смањење coupling-а у мобилном развоју. Уместо да класа самостално креира своје зависности, DI-контејнер (Hilt, Koin, Dagger за Android; Swinject, Factory за iOS) их обезбеђује споља. Класа прима зависности кроз constructor, method или property injection, остајући неупућена у конкретне имплементације.

DI експлицитно документује зависности класе: довољно је погледати конструктор да би се разумело са којим модулима класа комуницира. Ако конструктор прима 8 параметара из различитих слојева — то је сигнал прекомерног coupling-а који захтева рефакторисање. Добра пракса — не више од 3-4 зависности по класи. Већи број указује на кршење Single Responsibility и прекомерни coupling.

DI такође поједностављује тестирање: за сваки тест креирате класу са мок-зависностима, без потребе за правом базом података или мрежом. У Flutter-у DI се имплементира кроз Provider, Riverpod или GetIt. Без обзира на фрејмворк, циљ је један: ослабити повезаност између модула, чинећи зависности експлицитним и замењивим. Примена DI у мобилном пројекту је де факто стандард од 2020-их година.

// DI-контејнер саставља граф зависности
protocol AuthServiceProtocol {
    func login(email: String, password: String) async throws -> User
}

final class AuthService: AuthServiceProtocol {
    func login(email: String, password: String) async throws -> User {
        // имплементација
    }
}

// ViewModel не зна за конкретан сервис — само протокол
final class LoginViewModel {
    private let auth: AuthServiceProtocol

    init(auth: AuthServiceProtocol) {
        self.auth = auth
    }
}

// DI Container — једино место где се стварају конкретни типови
final class DIContainer {
    lazy var authService: AuthServiceProtocol = AuthService()
    lazy var loginViewModel: LoginViewModel {
        LoginViewModel(auth: self.authService)
    }
}

Овде LoginViewModel зависи само од протокола AuthServiceProtocol, а не од конкретног AuthService-а. Замена имплементације (на пример, прелазак са Firebase Auth на сопствени сервер) захтева промене само у DIContainer-у. Сви потрошачи AuthServiceProtocol-а остају нетакнути — coupling је сведен на минимум кроз апстракцију и DI.