Přejít k navigační liště

Zdroják » Různé » GRASP – 5 – Information expert a Creator

GRASP – 5 – Information expert a Creator

Články ‐ ‐ Různé ‐

V tomto díle o návrhových principech GRASP (General Responsibility Assignment Software Patterns) se budeme zabývat principy Information Expert – Informační expert a Creator – Tvůrce, které představují základní principy při výběru konkrétních objektů pro přidělení zodpovědnosti podle GRASP.

V minulých dílech jsme se zabývali obecnějšími principy GRASP týkajícími se strukturních vlastností architektury a posuzování kvality různých variant návrhu. V tomto díle navážeme dvěma principy, které slouží právě k nalezení konkrétních variant, ze kterých bychom měli vybírat.

Information Expert – Informační expert

Princip Information expert je jednoduchou poučkou říkající nám, jaké objekty zvažovat pro přidělení zodpovědnosti. Jde o základní vodítko používané při objektovém návrhu podle GRASP:

Zodpovědnost přidělte informačnímu expertovi – prvku, který má informace potřebné pro splnění této zodpovědnosti.

Tento princip je znám také v několik dalších variantách jako: „Umisťujte zodpovědnosti u dat.“ „Ten kdo to ví, ten to dělá.“ nebo „Udělám to [práci se svými daty] sám.“

Pokud zodpovědnosti přiřadíme třídám, které obsahují data nezbytná pro jejich provedení, vyhneme se tak nutnosti tato data získávat z jiných míst. Díky tomu nezávisíme na dalších prvcích a je tak podpořena Slabá provázanost – Low coupling.

Vezměme jednoduchý příklad zodpovědnosti objevující se v každém e-shopu: Který objekt má umět spočítat celkovou cenu objednávky? Začneme tím, že si položíme otázku: Který objekt má k tomu potřebné informace? V tomto případě to bude evidentně objekt reprezentující samotnou objednávku. Neměli bychom tedy zodpovědnost přidělovat jinému objektu – například třídě spravující seznam objednávek nebo třídě starající se o zobrazení objednávky.

Princip oživení (Animation principle)– Zodpovědnosti v objektovém návrhu nemůžeme vždy přidělovat v analogii skutečného světa. Například objednávka v reálném světě není schopná sama spočítat svoji celkovou cenu, protože jde o neživý objekt, který nic dělat nemůže. V reálném světě to musí udělat místo ní někdo živý (účetní). Ve světě objektového návrhu ale považujeme všechny objekty za živé – schopné vykonávat činnosti. 

Naplnění zodpovědnosti často vyžaduje informace rozptýlené ve více třídách a objektech. V takovém případě musí tyto třídy a objekty interagovat a rozdělit si práci. Ideální je se ale stále držet zásady Information expert a hlavní díl zodpovědnosti přidělit objektu, jež obsahuje nejvíce potřebných dat a který si zbylá data získá od ostatních objektů sám.

Existují případy, kdy řešení vyplývající z použití principu Informační expert jsou nevhodná. Obvykle kvůli problémům s vysokou provázaností a nebo nízkou soudržností.

Například: Kdo by měl být zodpovědný za uložení dat objednávky do databáze? Při aplikaci principu Informační expert by to měla být samotná objednávka. Toto rozhodnutí by ale způsobilo, že každý perzistentní objekt by musel sám implementovat funkčnost pro své uložení do databáze. Přestože tedy tento princip ospravedlňuje toto řešení, kvůli nízké soudržnosti a vysokému provázání takového návrhu jde o chybné rozhodnutí.

Využívání tohoto principu podporuje ideu zapouzdření– tedy že objekt se svými daty pracuje sám a nevystavuje je navenek. Díky tomu je podpořena nízká provázanost – čím méně toho třída vystaví navenek tím je méně příležitostí k provázání. Současně je také podpořena vysoká soudržnost, protože data a práce s nimi jsou umístěny pohromadě.

Creator – Tvůrce

Princip Creator – Tvůrce se zabývá otázkou, komu přidělit zodpovědnost za vytváření instancí objektů. Jeho znění je:

Přiřaďte třídě B zodpovědnost za vytváření instancí třídy A, pokud platí jedno nebo více z následujících:

  • B je agregátor objektů A
  • B obsahuje objekty A
  • B uchovává záznamy o objektech A
  • B úzce spolupracuje s objekty A
  • B má inicializační data pro A (B je informační expert pro inicializaci A)

Vytváření instancí je velice častým úkolem. Základní myšlenkou tohoto principu je přiřadit tuto odpovědnost takovému objektu (tvůrci), který by byl s vytvářeným objektem v každém případě propojený. Díky tomu nevznikne žádná další zbytečná vazba a je tím snižována provázanost.

Princip Tvůrce navrhuje, že dobrým kandidátem na vytváření objektů jsou třídy, které slouží jako kontejnery pro vytvářené objekty. Případně pokud jsou pro vytváření objektů potřebná nějaká inicializační data, je často jako tvůrce určen objekt, který tato data obsahuje,a by je nebylo nutné někam předávat. V druhém případě jde v podstatě o aplikaci principu Informační expert na vytváření objektů.

Dalším důsledkem aplikace tohoto principu je omezení míst, na kterých dochází k vytváření instancí – zodpovědnost za tvorbu instancí je omezena na jednu (případně několik) tříd, které splňují dané podmínky. Jde tedy o princip, jímž je motivován i návrhový vzor factory method.

Někdy je vytváření objektů komplexnější operací, vyžadující další logiku. V takových případech se doporučuje pro vytváření instancí vytvořit vlastní pomocnou třídu (např. návrhové vzory Abstract Factory a Builder) a přiřadit tuto zodpovědnost jí.

Závěr

Principy popsané v tomto díle by měly sloužit především pro nalezení základních variant toho, kam přiřadit zodpovědnosti. Ne vždy jsou ale tato řešení jednoznačná a často jsou v rozporu s jinými principy. Představují však výchozí bod našeho řešení. Pokud však nemáme jasný důvod, proč naši architekturu udělat jinak, je výhodné se jich držet.

Pokračování příště

V dalším díle se podíváme na poslední GRASP princip – Controller a celý seriál uzavřeme.

Zdroje a další informace

Komentáře

Odebírat
Upozornit na
guest
2 Komentářů
Nejstarší
Nejnovější Nejvíce hlasů
Tom

Ahoj,
děkuji ya velmi zajímavou serii článků.
Tom

bn

musím se taky přidat k poděkování – po nejaké době je to další seriál, který mě opravdu zaujal a hltám každý jeho díl i když většinu informací v „nějaké formě“ už dávno znám :)

AI přepracovala 300 tisíc řádků Street Fighteru III. Hlídal ji hash každého snímku

‐ AI ‐
Komentáře: 0
AI agenti za tři týdny přepracovali dekompilovaný kód Street Fighteru III: 3rd Strike a podle metriky CodeScene dosáhli nejvyššího možného skóre kvality. Shoda s původní verzí se ověřovala přehráváním herních záznamů a porovnáním hashe herního stavu po každém snímku. Taková kontrola je přísnější než běžné testy, zachytí ale jen to, co do hashe vstupuje.

DressCode si vezme váš PHP kód do parády

‐ PHP ‐
Komentáře: 0
Napsat nové pravidlo do PHP CS Fixeru nebo PHP_CodeSnifferu je za trest. David Grudl to zkusil kvůli jedinému řádku `use function` a místo pravidla z toho vznikl nový nástroj DressCode, postavený nad stromem, který ze zdrojáku nic nezahodí. Ukážeme si, jak ho nasadit, nastavit a zapojit do práce AI agenta.

Proč Anthropic ve svém monorepozitáři opustil Git? AI agenti změnili pravidla hry

‐ Různé ‐
Komentáře: 0
Anthropic nahradil Git ve svém hlavním monorepozitáři vlastním systémem Scion. Důvodem je prudký nárůst změn vytvářených s pomocí AI agentů: zatímco v květnu 2026 firma začleňovala přibližně 2 500 změn denně, v září jich bylo přes 30 000. Nový systém přesouvá správu historie na server, omezuje stahování nepotřebných dat a zrychluje přípravu kódu pro testování. Nejde však o univerzální náhradu Gitu.