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

Subscribe
Upozornit na
guest
2 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
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 :)

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.

Pocta C64

Za prvopočátek své programátorské kariéry vděčím počítači Commodore 64. Tehdy jsem genialitu návrhu nemohl docenit. Dnes dokážu lehce nahlédnout pod pokličku. Chtěl bych se o to s vámi podělit a vzdát mu hold.