Coupling (provázanost) v mobilním vývoji — klíčové pojmy, typy a jak ji snížit

Co je Coupling

Coupling (provázanost) je metrika, která určuje, jak silně je jeden modul nebo třída propojena s jiným. Čím více jeden modul ví o vnitřní struktuře druhého, tím vyšší je coupling a tím obtížnější je systém měnit. V dobře navržené architektuře by měl být coupling minimální — moduly komunikují pouze přes přesně definovaná rozhraní.

Rozlišujeme dvě strany couplingu: afferent (přicházející závislosti — kolik modulů závisí na daném) a efferent (odcházející závislosti — na kolika modulech daný modul závisí). Analýza těchto metrik umožňuje identifikovat "horká místa" v architektuře, kde změna jednoho modulu ovlivní mnoho dalších. Nástroje jako IntelliJ Dependency Analyzer a Xcode Graph vizualizují tyto vazby.

Je důležité pochopit, že nulový coupling je nemožný — moduly musí nějak komunikovat, jinak to není systém, ale soubor izolovaných programů. Úkolem architekta je učinit coupling řiditelným a transparentním. Ideál: moduly komunikují pouze přes rozhraní a předávají jen jednoduchá data, aniž by znaly vnitřní strukturu jeden druhého. Tomu se říká loose coupling (slabá provázanost).

Typy provázanosti od slabé k silné

Šest typů couplingu tvoří stupnici od nejlepšího po nejhorší. Pochopení této stupnice pomáhá hodnotit stávající kód a vybrat směr refaktorování. Většina mobilních projektů má smíšené typy couplingu a úkolem architekta je postupně nahrazovat silné typy slabými.

Data coupling — nejlepší typ

Data coupling (datová provázanost) — moduly si vyměňují pouze jednoduchá data prostřednictvím parametrů metod. Modul A volá metodu modulu B, předává primitiva nebo jednoduché struktury a dostává výsledek. Modul A neví, jak je B implementován uvnitř. Toto je nejžádanější typ couplingu: minimalizuje důsledky změn.

Příklad: EmailValidator.isValid(email: String): Boolean. Spotřebitelská třída předává řetězec a dostává Boolean, aniž by měla ponětí o regulárních výrazech nebo pravidlech validace uvnitř validatoru. Změna logiky validace nevyžaduje změnu spotřebitele — coupling je minimální. Data coupling je cílem pro všechna veřejná rozhraní v aplikaci.

Stamp coupling — přijatelný, ale ne ideální

Stamp coupling (strukturální provázanost) — moduly si vyměňují složené objekty, ale používají pouze část jejich polí. Modul A předává objekt User metodě calculateDiscount, která používá pouze user.status. Problém: pokud se struktura User změní (přidá se povinné pole), modul calculateDiscount se nezmění, ale spotřebitel, který vytváří objekt User, ano.

V praxi je stamp coupling nevyhnutelný a přijatelný, pokud je předávaný objekt standardním datovým modelem (Entity). Problém nastává, když modul obdrží celý objekt jen kvůli jednomu poli. V takových případech je lepší předávat konkrétní hodnotu přímo (data coupling). Řešení — analyzovat použití polí přijímající stranou.

Control, External, Common a Content coupling

Control coupling — jeden modul předává druhému příznak, který řídí jeho chování (calculate(useNewAlgorithm: Boolean)). To je horší než stamp coupling, protože spotřebitelský modul musí znát vnitřní varianty fungování volaného modulu. Řešení: rozdělit metodu na dvě — calculateWithNewAlgorithm() a calculateWithLegacyAlgorithm().

External coupling — moduly závisí na externím protokolu, formátu dat nebo API. Všechny moduly, které parsují stejný JSON nebo pracují se stejnou databází, mají external coupling. Zcela se mu vyhnout nelze, ale lze ho izolovat: vytvořit vrstvu mapování mezi externím formátem a vnitřními modely. Common coupling — moduly sdílejí společný globální stav. Content coupling — nejhorší typ, kdy modul přímo mění vnitřní data jiného modulu.

Stupnice couplingu od data (ideál) po content (katastrofa) — praktický nástroj pro code review. Pokud v projektu vidíte common nebo content coupling — to je prioritní cíl refaktorování. Data a stamp coupling jsou přijatelné a jsou přítomny v každém projektu, ale jejich počet by měl být kontrolován.

Proč je coupling kritický v mobilním vývoji

Vysoký coupling mění vývoj ve zpomalený proces, kde každá změna vyžaduje kontrolu desítek potenciálně rozbitých modulů. V mobilním vývoji je to obzvláště kritické: platformy se aktualizují ročně (Android API Level, iOS SDK), knihovny — čtvrtletně a obchodní požadavky — nepřetržitě. Slabá provázanost je jediný způsob, jak se vyrovnat s tímto proudem změn bez neustálých regresí.

Příklad z praxe: mobilní aplikace, kde všechny obrazovky přímo importují NetworkingManager a DatabaseManager. Při výměně HTTP klienta z Retrofit na Ktor (Android) nebo z URLSession na Alamofire (iOS) by musel vývojář opravit každou obrazovku. Při nízkém couplingu stačí změnit jednu implementaci skrytou za rozhraním NetworkDataSource — spotřebitelé si výměny nevšimnou.

Vliv couplingu na unit testování je také obrovský. Třída s vysokým couplingem (přímé vytváření závislostí přes konstruktor) nelze testovat izolovaně — táhne s sebou databázi, síť a UI. Pro testování takové třídy je třeba spustit emulátor a čekat na integrační testy. Třída s nízkým couplingem přijímá závislosti přes constructor injection a lze ji snadno mockovat.

// Vysoký coupling — třída si sama vytváří své závislosti
class ProfileViewModelHigh {
    private val api = RetrofitApi()
    private val db = RoomDatabase.getInstance()
    private val cache = MemoryCache()
}

// Nízký coupling — závislosti jsou předávány přes konstruktor
class ProfileViewModelLow(
    private val api: ApiService,
    private val db: DatabaseService,
    private val cache: CacheService
)

V prvním případě je ProfileViewModelHigh pevně připoután ke konkrétním implementacím — výměna Retrofit za Ktor vyžaduje změnu kódu ViewModelu. V druhém případě ProfileViewModelLow závisí pouze na rozhraních, jejichž implementace jsou dodávány zvenčí. Testování druhé třídy je triviální: předáme mock-implementace a zkontrolujeme logiku bez emulátoru.

Vzory pro snížení couplingu

Dependency Inversion Principle (D v SOLID) — základ pro snížení couplingu. Princip nařizuje záviset na abstrakcích, nikoli na konkrétních implementacích. Místo toho, aby třída přímo vytvářela objekt RetrofitApi, měla by obdržet rozhraní ApiService. To přesouvá vazbu z konkrétní knihovny na úroveň abstrakce, kterou lze vyměnit bez změny spotřebitele.

Observer pattern (nebo jeho reaktivní verze — StateFlow, Combine Publishers) snižuje coupling mezi zdrojem dat a odběrateli. Odběratel neví, odkud data pocházejí — pouze reaguje na změny. To odděluje odesílatele a příjemce: lze přidat nový zdroj dat beze změny stávajících odběratelů. EventBus a SharedFlow fungují na stejném principu.

Bridge pattern odděluje abstrakci a implementaci, což jim umožňuje měnit se nezávisle. V mobilním vývoji se Bridge používá například pro platformově závislé moduly: společné rozhraní ImageLoader s různými implementacemi pro iOS (Kingfisher, Nuke) a Android (Glide, Coil). Kód pracující s ImageLoaderem nezávisí na zvolené knihovně a může ji nahradit jednoduchou změnou implementace.

Dependency Injection jako nástroj správy couplingu

Dependency Injection (DI) — nejpraktičtější nástroj pro snížení couplingu v mobilním vývoji. Místo toho, aby si třída sama vytvářela své závislosti, DI-kontejner (Hilt, Koin, Dagger pro Android; Swinject, Factory pro iOS) je poskytuje zvenčí. Třída přijímá závislosti přes constructor, method nebo property injection, aniž by věděla o konkrétních implementacích.

DI explicitně dokumentuje závislosti třídy: stačí se podívat na konstruktor, abyste pochopili, se kterými moduly třída komunikuje. Pokud konstruktor přijímá 8 parametrů z různých vrstev — to je signál nadměrného couplingu vyžadujícího refaktorování. Dobrou praxí jsou maximálně 3-4 závislosti na třídu. Vyšší počet naznačuje porušení Single Responsibility a nadměrný coupling.

DI také zjednodušuje testování: pro každý test vytvoříte třídu s mock-závislostmi, aniž byste potřebovali skutečnou databázi nebo síť. Ve Flutter se DI implementuje přes Provider, Riverpod nebo GetIt. Bez ohledu na framework je cíl jediný: oslabit propojení mezi moduly tím, že závislosti budou explicitní a vyměnitelné. Použití DI v mobilním projektu je de facto standard od roku 2020.

// DI-kontejner sestavuje graf závislostí
protocol AuthServiceProtocol {
    func login(email: String, password: String) async throws -> User
}

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

// ViewModel neví o konkrétní službě — pouze protokol
final class LoginViewModel {
    private let auth: AuthServiceProtocol

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

// DI Container — jediné místo, kde jsou vytvářeny konkrétní typy
final class DIContainer {
    lazy var authService: AuthServiceProtocol = AuthService()
    lazy var loginViewModel: LoginViewModel {
        LoginViewModel(auth: self.authService)
    }
}

Zde LoginViewModel závisí pouze na protokolu AuthServiceProtocol, nikoli na konkrétním AuthService. Výměna implementace (například přechod z Firebase Auth na vlastní server) vyžaduje změny pouze v DIContainer. Všichni spotřebitelé AuthServiceProtocol zůstávají nedotčeni — coupling je snížen na minimum prostřednictvím abstrakce a DI.