GRASP – 5 – Information expert a Creator

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.

Seriál: Principy objektově orientovaného návrhu (12 dílů)

  1. Návrhové principy: SOLID 9.5.2012
  2. Návrhové principy: Deméteřin zákon 18.5.2012
  3. Návrhové principy: DRY 30.5.2012
  4. GRASP – 1 – Úvod a Protected variations 20.6.2012
  5. GRASP – 2 – High cohesion 2.7.2012
  6. GRASP – 3 – Low coupling 16.7.2012
  7. GRASP – 4 – Polymorphism, Pure fabrication a Indirection 30.7.2012
  8. GRASP – 5 – Information expert a Creator 15.8.2012
  9. GRASP – 6 – Controller a jak GRASP používat 17.9.2012
  10. GRASP – 7– Modelové příklady 15.10.2012
  11. Návrhové principy: Tvorba balíčků (1/2) – Soudržnost 14.11.2012
  12. Návrhové principy: Tvorba balíčků (2/2) – Závislosti a provázanost 14.1.2013

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

Martin Jonáš pracuje jako projektový manažer v GrowJOB institute. Vystudoval Informační systémy na Fakultě informačních technologií VUT.

Komentáře: 2

Přehled komentářů

Tom Poděkování
bn Re: Poděkování
Zdroj: https://www.zdrojak.cz/?p=3696