Cuplarea (Coupling) în dezvoltarea mobilă — concepte cheie, tipuri și cum să o reduci

Ce este Coupling

Coupling (cuplarea) este o metrică care determină cât de puternic este legat un modul sau o clasă de alta. Cu cât un modul știe mai multe despre structura internă a altuia, cu atât coupling-ul este mai ridicat și sistemul mai greu de modificat. Într-o arhitectură bine proiectată, coupling-ul trebuie să fie minim — modulele interacționează doar prin interfețe strict definite.

Se disting două laturi ale coupling-ului: afferent (dependențe de intrare — câte module depind de unul dat) și efferent (dependențe de ieșire — de câte module depinde unul dat). Analiza acestor metrici permite identificarea „punctelor fierbinți" în arhitectură, unde modificarea unui modul va afecta multe altele. Instrumente precum IntelliJ Dependency Analyzer și Xcode Graph vizualizează aceste conexiuni.

Este important să înțelegem că coupling-ul zero este imposibil — modulele trebuie să interacționeze cumva, altfel nu este un sistem, ci un set de programe izolate. Sarcina arhitectului este să facă coupling-ul gestionabil și transparent. Ideal: modulele interacționează doar prin interfețe și transmit doar date simple, fără a cunoaște structura internă una alteia. Aceasta se numește loose coupling (cuplare slabă).

Tipuri de cuplare de la slabă la puternică

Șase tipuri de coupling formează o scară de la cel mai bun la cel mai rău. Înțelegerea acestei scări ajută la evaluarea codului existent și alegerea direcției de refactorizare. Majoritatea proiectelor mobile au tipuri mixte de coupling, iar sarcina arhitectului este să înlocuiască treptat tipurile puternice cu cele slabe.

Data coupling — cel mai bun tip

Data coupling (cuplare prin date) — modulele schimbă doar date simple prin parametrii metodelor. Modulul A apelează metoda modulului B, transmițând primitive sau structuri simple, și primește un rezultat. Modulul A nu știe cum este implementat B în interior. Acesta este cel mai dorit tip de coupling: minimizează consecințele modificărilor.

Exemplu: EmailValidator.isValid(email: String): Boolean. Clasa consumatoare transmite un șir și primește un Boolean, fără să aibă cunoștință despre expresiile regulate sau regulile de validare din interiorul validatorului. Modificarea logicii de validare nu necesită modificarea consumatorului — coupling-ul este minim. Data coupling este scopul pentru toate interfețele publice din aplicație.

Stamp coupling — acceptabil, dar nu ideal

Stamp coupling (cuplare prin structură) — modulele schimbă obiecte compuse, dar folosesc doar o parte din câmpurile lor. Modulul A transmite obiectul User metodei calculateDiscount, care folosește doar user.status. Problemă: dacă structura User se schimbă (se adaugă un câmp obligatoriu), modulul calculateDiscount nu se schimbă, dar consumatorul care creează obiectul User — da.

În practică, stamp coupling este inevitabil și acceptabil dacă obiectul transmis este un model standard de date (Entity). Problema apare când un modul primește un obiect întreg doar pentru un singur câmp. În astfel de cazuri, este mai bine să se transmită valoarea concretă direct (data coupling). Soluția — analizarea utilizării câmpurilor de către partea primitoare.

Control, External, Common și Content coupling

Control coupling — un modul transmite altuia un flag care îi controlează comportamentul (calculate(useNewAlgorithm: Boolean)). Este mai rău decât stamp coupling, deoarece modulul consumator trebuie să cunoască variantele interne de funcționare ale modulului apelat. Soluție: împărțirea metodei în două — calculateWithNewAlgorithm() și calculateWithLegacyAlgorithm().

External coupling — modulele depind de un protocol extern, format de date sau API. Toate modulele care parsează același JSON sau lucrează cu aceeași bază de date au external coupling. Nu poate fi evitat complet, dar poate fi izolat: crearea unui strat de mapare între formatul extern și modelele interne. Common coupling — modulele împart o stare globală comună. Content coupling — cel mai rău tip, când un modul modifică direct datele interne ale altui modul.

Scara coupling de la data (ideal) la content (catastrofă) — un instrument practic pentru code review. Dacă vezi în proiect common sau content coupling — acesta este scopul prioritar de refactorizare. Data și stamp coupling sunt acceptabile și prezente în orice proiect, dar numărul lor trebuie controlat.

De ce coupling-ul este critic în dezvoltarea mobilă

Coupling-ul ridicat transformă dezvoltarea într-un proces încetinit, unde fiecare modificare necesită verificarea a zeci de module potențial stricate. În dezvoltarea mobilă, acest lucru este deosebit de critic: platformele se actualizează anual (Android API Level, iOS SDK), bibliotecile — trimestrial, iar cerințele de afaceri — continuu. Cuplarea slabă este singura modalitate de a face față acestui flux de schimbări fără regresii constante.

Exemplu practic: o aplicație mobilă unde toate ecranele importă direct NetworkingManager și DatabaseManager. La înlocuirea clientului HTTP de la Retrofit la Ktor (Android) sau de la URLSession la Alamofire (iOS), dezvoltatorul ar trebui să modifice fiecare ecran. La coupling scăzut, este suficient să schimbi o singură implementare ascunsă în spatele interfeței NetworkDataSource — consumatorii nu vor observa înlocuirea.

Influența coupling-ului asupra testării unitare este de asemenea enormă. O clasă cu coupling ridicat (crearea directă a dependențelor prin constructor) nu poate fi testată izolat — trage după sine baza de date, rețeaua și UI. Pentru testarea unei astfel de clase trebuie să pornești emulatorul și să aștepți testele de integrare. O clasă cu coupling scăzut primește dependențele prin constructor injection și este ușor de mock-uit.

// Coupling ridicat — clasa își creează singură dependențele
class ProfileViewModelHigh {
    private val api = RetrofitApi()
    private val db = RoomDatabase.getInstance()
    private val cache = MemoryCache()
}

// Coupling scăzut — dependențele sunt transmise prin constructor
class ProfileViewModelLow(
    private val api: ApiService,
    private val db: DatabaseService,
    private val cache: CacheService
)

În primul caz, ProfileViewModelHigh este legat rigid de implementări concrete — înlocuirea Retrofit cu Ktor necesită modificarea codului ViewModel. În al doilea caz, ProfileViewModelLow depinde doar de interfețe, ale căror implementări sunt furnizate din exterior. Testarea celei de-a doua clase este trivială: transmitem implementări mock și verificăm logica fără emulator.

Patternuri pentru reducerea coupling-ului

Dependency Inversion Principle (D în SOLID) — baza pentru reducerea coupling-ului. Principiul prescrie să depindem de abstractizări, nu de implementări concrete. În loc ca o clasă să creeze direct un obiect RetrofitApi, ea ar trebui să primească interfața ApiService. Aceasta mută legătura de la o bibliotecă concretă la nivelul de abstractizare, care poate fi înlocuit fără a modifica consumatorul.

Observer pattern (sau versiunile sale reactive — StateFlow, Combine Publishers) reduce coupling-ul între sursa de date și abonați. Abonatul nu știe de unde provin datele — el doar reacționează la schimbări. Aceasta decuplează expeditorul și receptorul: se poate adăuga o nouă sursă de date fără a modifica abonații existenți. EventBus și SharedFlow funcționează pe același principiu.

Bridge pattern separă abstractizarea de implementare, permițându-le să se schimbe independent. În dezvoltarea mobilă, Bridge se aplică, de exemplu, pentru modulele dependente de platformă: o interfață comună ImageLoader cu implementări diferite pentru iOS (Kingfisher, Nuke) și Android (Glide, Coil). Codul care lucrează cu ImageLoader nu depinde de biblioteca aleasă și o poate înlocui printr-o simplă schimbare a implementării.

Dependency Injection ca instrument de gestionare a coupling-ului

Dependency Injection (DI) — cel mai practic instrument de reducere a coupling-ului în dezvoltarea mobilă. În loc ca o clasă să-și creeze singură dependențele, containerul DI (Hilt, Koin, Dagger pentru Android; Swinject, Factory pentru iOS) le furnizează din exterior. Clasa primește dependențele prin constructor, method sau property injection, rămânând ignorantă față de implementările concrete.

DI documentează explicit dependențele clasei: este suficient să te uiți la constructor pentru a înțelege cu ce module interacționează clasa. Dacă constructorul primește 8 parametri din diferite straturi — acesta este un semnal de coupling excesiv, care necesită refactorizare. O practică bună — nu mai mult de 3-4 dependențe per clasă. Un număr mai mare indică încălcarea Single Responsibility și coupling excesiv.

DI simplifică și testarea: pentru fiecare test creezi o clasă cu dependențe mock, fără a necesita o bază de date reală sau rețea. În Flutter, DI se implementează prin Provider, Riverpod sau GetIt. Indiferent de framework, scopul este același: slăbirea legăturilor între module, făcând dependențele explicite și înlocuibile. Aplicarea DI într-un proiect mobil este un standard de facto din anii 2020.

// Containerul DI construiește graful de dependențe
protocol AuthServiceProtocol {
    func login(email: String, password: String) async throws -> User
}

final class AuthService: AuthServiceProtocol {
    func login(email: String, password: String) async throws -> User {
        // implementare
    }
}

// ViewModel nu știe de un serviciu concret — doar protocolul
final class LoginViewModel {
    private let auth: AuthServiceProtocol

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

// DI Container — singurul loc unde se creează tipuri concrete
final class DIContainer {
    lazy var authService: AuthServiceProtocol = AuthService()
    lazy var loginViewModel: LoginViewModel {
        LoginViewModel(auth: self.authService)
    }
}

Aici LoginViewModel depinde doar de protocolul AuthServiceProtocol, nu de un AuthService concret. Înlocuirea implementării (de exemplu, trecerea de la Firebase Auth la propriul server) necesită modificări doar în DIContainer. Toți consumatorii AuthServiceProtocol rămân neatinși — coupling-ul este redus la minimum prin abstractizare și DI.