Soudržnost (Cohesion) ve vývoji mobilních aplikací: základy, úrovně a jak ji zvýšit

Co je to Cohesion

Cohesion (soudržnost) — metrika, která hodnotí, jak logicky jsou propojeny metody, pole a vlastnosti uvnitř jedné třídy nebo modulu. Modul s vysokou soudržností vykonává jeden úkol a obsahuje pouze ty prvky, které jsou pro jeho splnění nezbytné. Modul s nízkou soudržností se snaží dělat několik věcí najednou — metody jsou významově slabě propojeny.

V kontextu objektově orientovaného programování soudržnost úzce souvisí s principem Single Responsibility (S). Pokud má třída jednu jasnou odpovědnost, její soudržnost je obvykle vysoká. Pokud se třída zabývá UI, business logikou i prací se sítí — soudržnost je nízká a takovou třídu je vhodné rozdělit na několik samostatných tříd s užší odpovědností.

Porozumění cohesion pomáhá vývojáři rozhodovat se o refaktoringu. Když vidíte, že ve třídě existuje metoda, která nepoužívá pole třídy, je to signál nízké soudržnosti. Taková metoda je buď ve třídě zbytečná, nebo je třída nesprávně navržena. Usilování o vysokou soudržnost je neustálá práce na zlepšování architektury na každé úrovni kódu.

Typy a úrovně soudržnosti

V softwarovém inženýrství rozlišujeme sedm úrovní soudržnosti, od nejhorší po nejlepší. Porozumění této škále umožňuje objektivně posoudit kvalitu modulu a pochopit, jakým směrem se ubírat při refaktoringu. Čím vyšší úroveň, tím udržovatelnější a srozumitelnější kód bude.

Nízká soudržnost: náhodná, logická a časová

Náhodná (coincidental) — nejhorší úroveň, kdy jsou prvky v modulu seskupeny náhodně, bez jakékoli logické souvislosti. Příklad: třída Utilities, ve které jsou shromážděny metody formátování data, odesílání e-mailu a výpočtu slevy. Takovou třídu nelze pochopit bez přečtení všech metod a změna jedné metody může rozbít jiné jen proto, že jsou vedle sebe.

Logická (logical) soudržnost — prvky vykonávají logicky související, ale svou podstatou různé úkoly. Třída s metodami parseJSON, parseXML a parseCSV je logicky spojena tématem „parsování“, ale každá metoda dělá zásadně odlišnou práci. Problém: při přidání nového formátu (YAML) třída roste a její rozhraní se nafukuje.

Časová (temporal) soudržnost — prvky jsou seskupeny podle času provedení. Třída AppInitializer, která nastavuje databázi, načítá konfiguraci, inicializuje analytiku — vše se děje při spuštění aplikace, ale samotné úkoly spolu nesouvisí. Lepší je rozdělit je na samostatné Initializery pro každou oblast odpovědnosti.

Střední soudržnost: procedurální a komunikační

Procedurální (procedural) soudržnost vzniká, když jsou prvky spojeny posloupností provádění. Modul „Zpracování objednávky“ obsahuje metody validateCart, processPayment, sendConfirmation — každá metoda je volána striktně po předchozí. To je lepší než náhodná nebo logická soudržnost, ale stále to není ideál: každý krok může být vyčleněn do samostatného modulu.

Komunikační (communicational) soudržnost — prvky pracují se stejnými daty. Třída UserService s metodami getUser, updateUser, deleteUser je spojena společnou entitou User. To je podstatně lepší než procedurální soudržnost: třída má jasnou věcnou oblast. Většina Repository tříd v mobilních projektech má komunikační soudržnost.

Vysoká soudržnost: funkční

Funkční (functional) soudržnost — nejvyšší úroveň, kdy se každý prvek modulu podílí na vykonávání jednoho úkolu. Třída PasswordValidator s jedinou metodou validate, která kontroluje délku, přítomnost znaků a složitost hesla — příklad funkční soudržnosti. Pokud se taková třída mění, pak jen proto, že se změnila pravidla pro validaci hesel.

Dosažení funkční soudržnosti je hlavním cílem architektonického refaktoringu. Každá třída by měla mít přesně jeden důvod ke změně. V mobilním vývoji se funkční soudržnosti dosahuje vyčleněním samostatných Use Cases, vlastních View, formátovačů a validátorů. Každá taková třída je hotový stavební blok s jasnou oblastí odpovědnosti.

Cohesion vs Coupling

Cohesion a coupling — dvě strany jedné kvality. Čím vyšší je soudržnost uvnitř modulu, tím nižší je obvykle provázanost mezi moduly. Dobře navržený systém současně usiluje o vysokou soudržnost uvnitř a slabou provázanost navenek. Toto pravidlo je považováno za zásadní v softwarovém inženýrství od 70. let 20. století.

Vztah cohesion-coupling lze představit jako rovnováhu. Pokud vývojář obětuje soudržnost, spojením několika úkolů do jedné třídy, sousední moduly získají více závislostí — musí se obracet na tuto přetíženou třídu pro různé účely, což zvyšuje provázanost. A naopak, rozdělení na malé třídy s vysokou soudržností snižuje počet bodů interakce mezi moduly.

V praxi to znamená: když vyčleňujete novou třídu s funkční soudržností, zároveň zbavujete ostatní moduly nutnosti znát detaily její implementace. Například vyčleněním EncryptionManager do samostatné třídy s funkční soudržností poskytujete ostatním modulům jednoduché rozhraní encrypt/decrypt bez nutnosti rozumět detailům šifrovacího algoritmu.

// Nízká soudržnost — třída dělá všechno najednou
class UserManager {
    fun fetchAndSaveUser(id: String) { }
    fun parseUserJson(json: String): User { }
    fun displayUserName(user: User): String { }
    fun validateEmail(email: String): Boolean { }
}

// Vysoká soudržnost — každá třída řeší jeden úkol
class UserRepository {
    fun fetchUser(id: String): User { }
}

class UserJsonParser {
    fun parse(json: String): User { }
}

class UserNameFormatter {
    fun format(user: User): String { }
}

class EmailValidator {
    fun isValid(email: String): Boolean { }
}

Příklad ukazuje rozdíl: UserManager má logickou soudržnost — všechny metody jsou o uživatelích, ale každá dělá zásadně odlišnou práci. Po refaktoringu má každá třída funkční soudržnost a provázanost se snižuje, protože ostatní moduly závisí pouze na třídě, kterou potřebují, a ne na celém UserManager.

Jak měřit soudržnost v kódu

LCOM (Lack of Cohesion of Methods) — nejznámější metrika pro měření soudržnosti třídy. LCOM vypočítává, kolik párů metod nepoužívá společná pole. Hodnota 0 znamená ideální soudržnost (všechny metody pracují se stejnými poli), vysoká hodnota znamená nízkou soudržnost. LCOM4 (vylepšená verze) zohledňuje tranzitivní vazby přes jiné metody.

V Android vývoji lze metriky soudržnosti získat pomocí Detekt s pravidlem TooManyFunctions. Třídy s desítkou metod používajících různé skupiny polí mají pravděpodobně nízkou soudržnost. V iOS má SwiftLint pravidla file_length a function_body_length — nepřímé indikátory: dlouhé soubory a metody často signalizují nízkou soudržnost.

Ruční způsob hodnocení: položte si otázku „Změní se tato třída z jednoho důvodu nebo z několika?“ Pokud dokážete uvést více než jeden nezávislý důvod — třída má nízkou soudržnost. Druhý test: „Lze tuto třídu rozdělit na dvě nezávislé třídy?“ Pokud ano — udělejte to. Pravidelná kontrola soudržnosti při code review zabraňuje vzniku God tříd a snižuje technický dluh.

Jak zvýšit Cohesion v mobilním projektu

První krok — aplikujte princip Single Responsibility. Každá třída by měla mít jednu jasnou odpovědnost. Pokud je ve třídě metoda, která nepatří k jejímu hlavnímu úkolu, přeneste ji do samostatné třídy. Technika Extract Class nebo Extract Delegate v IDE tento proces automatizuje. Po vyčlenění zkontrolujte, zda se původní třída stala více zaměřenou.

Druhý krok — použijte vzor Facade pro zjednodušení rozhraní. Pokud třída poskytuje 20 metod, z nichž klienti používají jen 3-4, má třída pravděpodobně nízkou soudržnost — poskytuje příliš mnoho různé funkcionality. Seskupte metody podle témat a vyčleňte samostatné třídy pro každou skupinu, původní třídu pak udělejte fasádou nebo ji odstraňte.

Třetí krok — věnujte pozornost skupinám polí. Pokud má třída pole, která jsou používána pouze částí metod — je to indikátor nízké soudržnosti. Rozdělte třídu podle skupin polí. Například pokud třída obsahuje pole userRepository, networkClient a analyticsTracker, ale metody první skupiny používají pouze userRepository, zatímco druhé skupiny pouze networkClient — jedná se o dvě různé třídy.

Čtvrtý krok — vyhýbejte se vytváření „pomocných“ tříd s libovolnými static metodami. Každá static metoda nacházející se ve třídě Utils nebo Helpers je kandidátem na vyčlenění do specializované třídy. FormatUtils.dateToString je lepší přesunout do DateFormatter a ValidationUtils.isValidEmail do EmailValidator. To zvyšuje soudržnost každé třídy a činí kód samodokumentujícím.