Návrhové vzory, GoF, GRASP, UML sekvenční a tříd

BI-WI.21-12

Vzory používané během návrhu:

  • třívrstvá architektura,
  • Model View Controller,
  • GoF vzory (Abstraktní továrna, Stav, Adaptér),
  • GRASP vzory (Nízká provázanost, Vysoká soudržnost),
  • popis spolupráce objektů (UML sekvenční diagram, UML diagram tříd).

Vzory používané během návrhu

  • Cílem návrhových vzorů a principů je vytvářet kvalitní, znovupoužitelný, škálovatelný a snadno udržovatelný software.
  • Poskytují osvědčená řešení pro opakující se problémy v softwarovém inženýrství.

Architektonické vzory

Třívrstvá architektura

  • Třívrstvá architektura rozděluje aplikaci do tří logicky a fyzicky oddělitelných vrstev. Jde o jeden z nejběžnějších přístupů pro distribuované systémy.

  • Účel

    • Oddělení zodpovědnosti (Separation of Concerns),
    • zvýšení škálovatelnosti a usnadnění údržby.
    • Každou vrstvu lze spravovat nezávisle na ostatních.
  • Vrstvy

    • Prezentační vrstva - Zodpovídá za zobrazení dat a interakci s uživatelem (GUI, webové rozhraní). Neobsahuje žádnou aplikační logiku.
    • Business (doménová) vrstva - Zpracovává hlavní byznys logiku aplikace, provádí výpočty a rozhodovací procesy. Funguje jako prostředník mezi prezentační a datovou vrstvou.
    • Datová vrstva - Zodpovídá za ukládání, správu a extrakci dat z databáze nebo jiného úložiště
  • Druhy třívrstvé architektury

    • Striktní - závislost vždy směrem dolů, komunikace pouze o jednu úroveň
    • Relaxovaná - závislost vždy směrem dolů, přes libovolný počet úrovní - prakticky nejpoužívanější pro návrh IS
  • Výhody

    • Oddělení business logiky od prezentační vrstvy
    • Nezávislost business logiky na způsobu uložení
    • Snadná výměna jednotlivých vrstev
    • Jednoduché testování
    • Více různých prezentačních vrstev
    • Znovupoužitelnost - nižší vrstvy lze použít na více projektech (např. služby pro logování, odesílání emailů, persistenci apod.)

../../Attachments/Pasted image 20260618182850.png

Vzor MVC (Model-View-Controller)

  • Vzor řešící problém prezentační vrstvy.

  • Založený na oddělení logiky od GUI.

  • Třívrstvá architektura.

  • Organizace kódu v rámci jedné aplikace, nejčastěji v prezentační vrstvě třívrstvé architektury.

  • Umožňuje paralelní vývoj a modifikaci jednotlivých částí.

  • Model

    • Reprezentuje data a byznys logiku aplikace.
    • Zodpovídá za správu stavu dat a notifikuje pohledy (Views) o změnách.
    • Je nezávislý na UI.
  • View

    • Zobrazuje data z modelu uživateli a předává uživatelské akce (kliky, vstupy) controlleru.
    • Může existovat více pohledů pro jeden model.
  • Controller

    • Reaguje na uživatelské akce z pohledu, zpracovává je a na základě toho manipuluje s modelem.
    • Říká modelu, aby změnil svůj stav.

../../Attachments/Pasted image 20260618183734.png

GoF vzory

  • Podle skupiny autorů "Gang of Four"
  • Rozdělení vzorů
    • Vzory pro vytváření objektů (Creational)
      • Abstract Factory
      • Builder
      • Singleton
      • Factory method
    • Vzory chování (Behavioral)
      • State
      • Observer
    • Strukturální vzory (Structural)
      • Adapter
      • Facade

Creational (Vytvářecí)

Abstract Factory

  • Řeší problém vytváření rodiny/varianty produktů
  • Abstraktní továrna definuje metody pro vytváření všech produktů
  • Konkrétní továrna musí tyto metody implementovat pro danou variantu produktů

../../Attachments/Pasted image 20260619125222.png

Builder

  • Odděluje konstrukci komplexního objektu od jeho reprezentace, takže stejný konstrukční proces může vytvářet různé reprezentace.
  • Umožňuje sestavovat objekty krok za krokem.
  • Je řízen Directorem - Určuje kdy a v jakém pořadí se mají kroky z Builderu zavolat. Odstiňuje klienta od nutnosti znát přesný algoritmus sestavování.

../../Attachments/Pasted image 20260619125501.png

Singleton

  • Zajišťuje, že třída má pouze jednu instanci a poskytuje globální přístupový bod k ní (např. pro databázové připojení, konfiguraci).

  • Často diskutovaný, někdy považován za anti-pattern kvůli problémům s testovatelností a globálním stavem.

  • Princip: Skryjeme konstruktor (private) a vytvoříme statickou metodu (getInstance()), která vrátí existující instanci, nebo ji při prvním zavolání vytvoří.

Factory Method

  • Definuje rozhraní pro vytváření objektu, ale nechává na podtřídách, aby rozhodly, kterou konkrétní třídu instancovat.
  • Princip: Místo volání new KonkretniTrida() se volá abstraktní metoda vyrob(). Tu si přepíší potomci podle sebe.

Behavioral (Chování)

State

  • Účel: Umožňuje objektu měnit své chování, když se změní jeho vnitřní stav. Z vnějšího pohledu se zdá, jako by objekt změnil svou třídu.
  • Kdy použít: Když má objekt mnoho stavů a jeho chování se v závislosti na nich výrazně mění (mnoho if/else nebo switch konstrukcí). Vzor zapouzdřuje chování spojené s konkrétním stavem do samostatné třídy.
  • Příklad: Objekt Objednávka může mít stavy jako Nová, Zpracovává se, Odeslaná, Zrušená. Pro každý stav existuje samostatná třída (StavNova, StavOdeslana), která implementuje metody jako odeslat() nebo zrusit(). Metoda odeslat() v Objednávce pouze deleguje volání na svůj aktuální stavový objekt.

../../Attachments/Pasted image 20260619131557.png

Observer

  • Definuje závislost jedna-k-mnoha mezi objekty tak, že když jeden objekt změní stav, všichni jeho závislí (pozorovatelé) jsou automaticky upozorněni a aktualizováni.

  • Řeší "polling", tedy aby se všechny ostatní objekty nemusely neustále ptát "už se to změnilo?"

  • Pozorující objekty se zaregistrují u pozorovaného objektu

  • Pozorující objekt musí implementovat požadované rozhraní

  • Při změně upozorní pozorovaný objekt všechny pozorující pomocí tohoto rozhraní

Structural (Strukturální)

Adapter

  • Účel: Umožňuje spolupráci objektů s nekompatibilními rozhraními. Funguje jako "překladač" nebo mezikus mezi dvěma různými rozhraními.
  • Kdy použít: Když chcete použít existující třídu, ale její rozhraní neodpovídá tomu, které potřebujete. Typicky při integraci knihoven třetích stran.

../../Attachments/Pasted image 20260619132442.png

GRASP vzory

GRASP = General Responsibility Assignment Software Patterns

  • Jsou to spíše principy nebo heuristiky, které pomáhají přiřazovat zodpovědnosti jednotlivým objektům v objektově orientovaném návrhu.

  • Zodpovědnost je úkol, který má třída řešit

  • Typy

    • Informační expert (Information Expert)
    • Nízká provázanost (Low Coupling)
    • Vysoká soudržnost (High Cohesion)
    • ... + 6 dalších

Informační expert

  • Základní princip přiřazení zodpovědnosti

  • Přiřaďte zodpovědnost třídě, která má informace potřebné pro splnění této zodpovědnosti

  • Příklad:

    • Který objekt má spočítat celkovou cenu objednávky?
    • Třída Objednavka, protože zná všechny své položky (PolozkaObjednavky) a jejich počet.
    • Ne nějaká manažerská třída VypocetCenyManager.

Nízká provázanost

  • Provázanost (Coupling) = měřítko toho, jak moc je jedna třída závislá na jiné. Cílem je minimalizovat závislosti mezi třídami.

  • Přiřazujte zodpovědnosti tak, aby provázanost (závislost jedné třídy na druhé) zůstala co nejnižší.

  • Důsledek:

    • Pokud je provázanost nízká, změna v jedné třídě má minimální dopad ostatní třídy. To usnadňuje údržbu systému.
  • Příklad:

    • Pokladna by neměla přímo záviset na třídě MySQLDatabase, ale na obecném rozhraní IDatabase.
    • Pokud pak vyměníte MySQL za PostgreSQL, nemusíte měnit kód pokladny.

Vysoká soudržnost

  • Soudržnost (Cohesion) = míra, do jaké spolu zodpovědnosti jedné třídy souvisejí

  • Přiřazujte zodpovědnosti tak, aby soudržnost zůstala vysoká.

  • Důsledek:

    • Systémy s vysokou soudržností jsou srozumitelnější, snáze se udržují a jsou robustnější. Opakem je tzv. "God Object" (Božský objekt), který dělá všechno a je noční můrou pro údržbu.
  • Příklad:

    • Třída Zakaznik by měla obsahovat jen data a metody týkající se zákazníka (jméno, adresa, historie objednávek).
    • Neměla by obsahovat logiku pro formátování tisku faktur nebo připojování k databázi. To patří jinam.

GRASP vs GoF

Aspekt GRASP GoF
Typ Principy, heuristiky, myšlenkové postupy Katalog konkrétních, osvědčených řešení
Účel Pomáhají přiradit zodpovědnosti a zdůvodnit návrhová rozhodnutí Poskytují hotové šablony pro řešení často se vyskytujících problémů
Abstrakce Vyšší (obecné rady) Nižší (konkrétní diagramy a implementace)
  • GRASP je “proč”
  • GoF je “jak”
  • Dobře aplikovaný GoF vzor je často demonstrací jednoho či více GRASP principů.

Popis spolupráce objektů

UML diagram tříd

  • Viz UML diagram tříd, otázka 11
  • V "reálném" (nekonceptuálním) stavu je detailnější, má popsané i metody, datové typy, viditelnost (private/protected/public) atd.

UML sekvenční diagram

  • Znázorňuje interakce mezi komponentami/třídami/aktéry v čase

../../Attachments/Pasted image 20260618184548.png
Ukázka vypůjčení výtisku

UML Notace

  • Objekt může být pojmenovaný (např. Objekt A u Třídy A) nebo nepojmenovaný (zapsáno jen jako :Třída B)
  • Zpráva může být asynchronní / synchronní

../../Attachments/Pasted image 20260618184925.png

  • Návratová hodnota lze zapsat dvěma způsoby
    • Přiřazení pomocí symbolu rovnítka
    • Separátní šipkou

../../Attachments/Pasted image 20260618185024.png

  • Vytvoření objektů pomocí přerušované šipky << create >>
  • Zrušení objektů pomocí křížku a anotace << destroy >>

../../Attachments/Pasted image 20260618185135.png

  • Fragmenty větvení a cyklu - rámeček s podmínkou v hranatých závorkách
  • Iterace přes prvky kolekce - rámeček, podmínka s iterační proměnnou i, (modrý) obdélník iterovaných objektů třídy (další sloupec)

../../Attachments/Pasted image 20260618185435.png


Vytvořeno: 20. 6. 2026, 13:15
Poslední aktualizace: 20. 6. 2026, 14:28