Architektonické principy v mobilním vývoji: co to je, jaké jsou typy a jak je aplikovat

Principy SOLID

Architektonické principy — jsou základem kvalitního kódu. SOLID je akronym zavedený Robertem Martinem («Strýček Bob») popisující pět principů objektově orientovaného návrhu. Dodržování SOLID činí kód flexibilnější, testovatelnější a odolnější vůči změnám. Porušování architektonických principů je jednou z hlavních příčin technického dluhu.

Pojďme prozkoumat každý princip. Single Responsibility Principle (SRP) — každá třída by měla mít pouze jeden důvod ke změně. Open/Closed Principle (OCP) — třídy jsou otevřené pro rozšíření, ale uzavřené pro modifikaci. Liskov Substitution Principle (LSP) — objekty podtypů by měly nahrazovat objekty základního typu bez narušení logiky. Interface Segregation Principle (ISP) — mnoho specializovaných rozhraní je lepších než jedno obecné. Dependency Inversion Principle (DIP) — závislost na abstrakcích, ne na konkrétních implementacích.

Podle analýzy SonarQube (2025) se porušování principů SOLID vyskytuje u 68% komerčních projektů. Nejčastějšími problémy jsou porušení SRP (35%) a ISP (22%). Ve IT Sectr zavádíme SOLID ve fázi architektonického přezkumu — to pomáhá identifikovat problémy dříve, než přerostou v technický dluh.

Single Responsibility Principle (SRP)

SRP (Princip jediné odpovědnosti) — nejdůležitější a zároveň nejčastěji porušovaný princip SOLID. Říká: třída by měla mít pouze jeden důvod ke změně. Pokud třída dělá příliš mnoho, je obtížné ji testovat, měnit a chápat.

Typickým porušením je třída, která současně zpracovává data, ukládá je do databáze a odesílá e-mailová upozornění. Níže uvedený příklad ukazuje porušení SRP v Kotlin a jak jej opravit.

// Porušení SRP — třída dělá tři různé věci
class UserService {
    fun registerUser(email: String, name: String) {
        // 1. Validace dat
        if (!email.contains("@")) throw IllegalArgumentException("Invalid email")
        
        // 2. Uložení do databáze
        val user = User(email, name)
        database.save(user)
        
        // 3. Odeslání upozornění
        emailService.sendWelcomeEmail(email, name)
    }
}

// Oprava — rozdělení do tří tříd
class UserRegistrationService {
    fun register(email: String, name: String) {
        UserValidator().validate(email)
        val user = User(email, name)
        UserRepository().save(user)
        NotificationService().sendWelcome(user)
    }
}

V opravené verzi je každá třída odpovědná za svůj vlastní úkol: UserValidator — za validaci, UserRepository — za ukládání, NotificationService — za upozornění. To činí kód testovatelným a znovupoužitelným — můžete vyměnit implementaci databáze bez změny logiky validace.

GRASP a Law of Demeter

GRASP (General Responsibility Assignment Software Patterns) — devět architektonických principů pro rozdělení odpovědnosti mezi objekty, popsaných Craigem Larmanem. Na rozdíl od SOLID, GRASP odpovídá na otázku «která třída by měla obsahovat tuto metodu?». Klíčové vzory: Information Expert, Creator, Controller, Low Coupling, High Cohesion, Polymorphism, Pure Fabrication, Indirection, Protected Variations.

Law of Demeter (LoD, princip minimální provázanosti) — jednoduché pravidlo: objekt by měl komunikovat pouze se svými bezprostředními sousedy. Nemělo by se psát a.getB().getC().doSomething() — to vytváří silnou provázanost mezi třídami. LoD zlepšuje znovupoužitelnost a zjednodušuje testování.

V IT Sectr kontrolujeme dodržování LoD během Code Review. Pokud metoda «prochází» třemi nebo více objekty, je to signál, že architekturu je třeba zjednodušit. Porušení LoD je jedním z nejčastějších Code Smell ve velkých projektech.

DRY / KISS / YAGNI

DRY (Don't Repeat Yourself), KISS (Keep It Simple, Stupid) a YAGNI (You Ain't Gonna Need It) — tři základní architektonické principy známé každému vývojáři. Navzdory své jednoduchosti k porušování dochází neustále.

DRY — nezdvojujte kód. Pokud se stejná logika objevuje na dvou místech, extrahujte ji do společné metody nebo třídy. Duplicita je hlavním zdrojem chyb: oprava na jednom místě se zapomene aplikovat na jiném. DRY neznamená, že nemůžete mít podobný kód — důležité je, aby se obchodní logika neopakovala.

KISS — čím jednodušší, tím lepší. Složitá řešení s mnoha abstrakcemi a dědičností jsou často přehnaná. Začněte s jednoduchým řešením a komplikujte ho pouze v případě potřeby. YAGNI — nepište kód pro funkcionalitu, která by mohla být potřebná «někdy později». To vede k nafouknutí kódové základny a zvýšení složitosti údržby.

DRY — Don't Repeat Yourself

DRY — nejde jen o absenci kopírování-vkládání. Je to princip, podle kterého by každý kousek znalosti nebo logiky měl mít v systému jedinou, jednoznačnou reprezentaci. Duplicita může být explicitní (zkopírovaný kód) a implicitní (stejná logika v různých vrstvách).

V IT Sectr používáme metriky analýzy kódu k detekci duplicity. Nástroje jako SonarQube a Detekt ukazují procento duplicitního kódu. Hodnota nad 5% je důvodem k refaktorování. Je však důležité si pamatovat: DRY by neměl být dosažen za cenu špatných abstrakcí — někdy je lepší nechat dva podobné kusy kódu tak, jak jsou, pokud by jejich spojení zkomplikovalo porozumění.

Separation of Concerns a Modularita

Separation of Concerns (SoC) — architektonický princip, kde je systém rozdělen na nezávislé části (concerns), každá řeší svůj vlastní úkol. Klasickým příkladem je rozdělení na vrstvy: prezentace, obchodní logika, přístup k datům. Každá vrstva závisí pouze na vrstvě pod ní.

Modularita — míra, do jaké lze systém rozdělit na moduly. Modul je logicky související skupina tříd s dobře definovaným rozhraním. Moduly by měly být volně provázané (low coupling) a silně soudržné (high cohesion).

Soudržnost vs Provázanost

Soudržnost (Cohesion) — míra toho, jak moc jsou prvky v rámci jednoho modulu vzájemně propojeny. Vysoká soudržnost je dobrá: třída dělá jednu věc a dělá ji dobře. Nízká provázanost (Low coupling) — míra toho, jak moc jsou moduly na sobě nezávislé. Nízká provázanost je dobrá: změna jednoho modulu nerozbíjí ostatní.

Ideální architektura je vysoká soudržnost a nízká provázanost. V praxi to znamená: třída obsahuje metody pracující na stejných datech (soudržnost) a závisí pouze na abstrakcích, ne na konkrétních implementacích (provázanost). Nerovnováha vede k «Božským objektům» nebo «špagetovému kódu».

Technický dluh a Code Smell

Technický dluh (Technical Debt) — metafora zavedená Wardem Cunninghamem popisující «úrok», který tým platí za suboptimální architektonická rozhodnutí a porušování architektonických principů. Stejně jako finanční dluh, technický dluh může být záměrný (rozhodli jsme se to udělat rychle, přepracujeme to později) a nezáměrný (špatná architektura kvůli nedostatku zkušeností).

Code Smell — povrchové znaky hlubokých problémů v kódu. Termín zpopularizoval Martin Fowler v knize «Refactoring». Typické Code Smell: dlouhé metody, velké třídy, dlouhé řetězce volání, duplicita kódu, nadměrné používání komentářů (místo jasného kódu).

V IT Sectr je technický dluh sledován v Jira jako samostatné úkoly. Každý sprint vyčleňujeme 20% času na refaktorování a splácení dluhu. Systematická práce s technickým dluhem je jediným způsobem, jak se vyhnout situaci, kdy přidání nové funkce trvá déle než její vývoj od nuly.