GRASP – 1 – Úvod a Protected variations

Přidělování zodpovědností (kdo bude co dělat) a návrh jejich kooperace je důležitým a netriviálním krokem při návrhu software. Návrhové principy GRASP (General Responsibility Assignment Software Patterns), které sestavil Craig Larman, nám k tomu poskytují užitečná vodítka. V prvním díle se seznámíme se základními pojmy a probereme princip Protected variations.

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

Zodpovědnosti

Zodpovědností (responsibility) rozumíme závazek nebo povinnost prvku (subsystému, třídy, objektu) něco:

  • Dělat – udělat něco sám, vyvolat akci jiného prvku a nebo tyto akce koordinovat
  • Vědět – znát svoje (privátní) data, znát související prvky a nebo umět něco odvodit či agregovat

Přidělování zodpovědností (responsibility assignment) je pak určování, která komponenta bude mít kterou zodpovědnost. Tato činnost je jádrem toho, co považujeme na návrh objektově orientovaného systému. Je to zásadní a netriviální krok navrhování, který vyžaduje značnou kreativitu a zvažování mnoha obvykle protichůdných faktorů.

Prvním krokem při přidělování zodpovědností je jejich definice. Ta závisí na tom, s jakou granularitou se na systém díváme. Zodpovědností může být jak „ukládání dat do databáze“, tak „sestavení WHERE podmínky SQL dotazu pro update zákazníka“. Vždy je nutné zvolit správnou úroveň granularity, kterou je potřeba v dané fázi navrhování použít. Samozřejmě bychom vždy měli začít hrubým přidělením zodpovědností a pak granularitu postupně zmenšovat.

Zodpovědnost není to samé co metoda. Konkrétní metody jsou implementovány, aby byla splněna zodpovědnost.

GRASP (General Responsibility Assignment Software Patterns)

GRASP je sada návrhových principů (vzorů), kterou sestavil Craig Larman ve své známé knize Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process.

Jde o sadu principů, které slouží jako pomůcka při rozhodování o přidělování zodpovědností. Tyto principy mají také sloužit jako společný slovník pojmů, umožňující zjednodušit diskuze o jednotlivých variantách návrhu.

Při návrhu není možné jednotlivé principy uvažovat samostatně, protože často jsou jejich požadavky proti sobě.  Správný způsob jak tyto principy používat je tedy ve zvážení všech pro a proti jednotlivých variant z pohledu všech principů.

Jednotlivé principy GRASP mají různou úroveň abstraktnosti. Některé z nich jsou pouze obecné zásady. Jiné představují konkrétní doporučovaná řešení.

GRASP se skládá celkem z 9 principů:

  • Protected variations – Chráněné změny
  • High cohesion – Vysoká soudržnost
  • Low coupling – Slabá provázanost
  • Pure fabrication – Pouhá konstrukce (znáte vhodnější překlad?)
  • Polymorphism
  • Indirection – Nepřímé vazby
  • Information expert – Informační expert/Expert
  • Creator – Tvůrce
  • Controller

(Pozn.: Uvedené pořadí neodpovídá tomu, jak tyto principy uvádí Larman a většina z něj vycházející literatury, ale jde od obecnějších principů ke konkrétnějším.)

Jednotlivé principy postupně podrobně rozebereme v následujících dílech. Dnes začneme prvním principem ze seznamu tedy Protected variations – chráněné změny.

Protected variations – Chráněné změny

Ve většině systémů se neustále provádějí změny – ať už při jejich vývoji tak později ve fázi údržby. Každá změna představuje riziko, že ostatní části systému nebudou fungovat tak, jak by měly. Jak se vyhnout tomu, aby tyto změny nevedly k nežádoucím důsledkům v dalších prvcích systému?

Identifikujte místa pravděpodobných změn a nestability a zodpovědnosti přiřaďte stabilním rozhraním, která kolem nich vytvoříte.

(Pozn.: Rozhraní v tomto smyslu nemusí nutně znamenat například interface v Javě, ale představuje obecnější koncept.)

Objekty budou spolupracovat pouze se stabilním rozhraním, které před nimi skryje případné změny v prvcích, které se za ním nacházejí. Budou tedy chráněny před důsledky změn za tímto rozhraním – proto chráněné změny. Prováděné změny pak budou mít více lokální charakter, čímž se značně sníží riziko chyby a množství práce nutné při provádění úprav.

Tento princip je jedním ze základních návrhových principů, který se v různých variantách objevuje již desetiletí. Jde o princip motivující většinu mechanismů a vzorů ve vývoji software. Zapouzdření, rozhraní, polymorfismus, nepřímé vazby a další mechanismy jsou nástroji k dosažení protected variations. Ze všech principů GRASP je tento princip nejabstraktnější.

Čím méně stabilní určité části systému jsou tím důležitější je dodržovat tento princip. 

Výhody

  • Provádění změn je jednodušší a více lokální
  • Změny nemají dalekosáhlé důsledky na ostatní prvky systému
  • Je snížena provázanost prvků systému
  • Náklady na provedení změn jsou sníženy

V některých případech může být výhodnější místo připravování systému na možné budoucí změny připravit jednodušší návrh, který bude v budoucnosti přepracován, pokud vyvstane potřeba změn. Místa, kde se pravděpodobně mohou objevit změny (points of change) totiž můžeme rozdělit na dva druhy:

  • Obměny (variation points) – změny existující v rámci existujícího systému (například různé varianty algoritmu pro výpočet daně).
  • Evoluční (evolution points) – místa změn, které se mohou objevit v budoucnosti, ale nejsou přítomné v existujícím systému.

Při návrhu bychom mezi těmito dvěma druhy měli rozlišovat. U obměn (variation points) nemáme na výběr, protože potřeba různých variant existuje již nyní. U evolučních bychom ale vždy měli zvážit, zda bude menší objem práce představovat přepracování návrhu v budoucnosti nebo jeho příprava na změny nyní.

Larmann ve své knize uvádí tři stádia, kterými obvykle vývojáři procházejí:

  • Nováčci vytvářejí návrh, který se změnami nepočítá a při potřebě změn se rozpadá.
  • Středně pokročilí vytvářejí přemrštěný návrh, který je sice flexibilní, elegantní a obecný, ale většina vložené práce se nikdy prakticky nevyužije.
  • Pokročilí si vybírají s rozvahou cestu mezi těmito dvěma extrémy.

Princip Protected variations má souvislost s řadou dříve probíraných principů.

Liskovové substituční princip z dílu o SOLID principech, který říká že „Podtřídy by měly být zaměnitelné s jejich bázovými třídami“, je motivován snahou chránit uživatele bázové třídy před změnami v různých implementacích této třídy.

Open-closed principle popsaný v díle o SOLID principech říká, že třídy by měly být otevřené k rozšíření (adaptabilní), ale uzavřené ke změnám, které by ovlivnily existující kód, který je využívá. Jeho cílem je tedy také vytvářet kód, ve kterém jsou minimalizovány důsledky změn na již existující kód.

Deméteřin zákon také probíraný v jednom z minulých dílů, nás motivuje, že bychom neměli odhalovat vnitřní strukturu našich objektů. Tím chráníme kód používající tyto objekty před důsledky změn jejich vnitřní struktury.

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

V příštích dílech budeme pokračovat principy High cohesion – Vysoká soudržnost a Low coupling – Slabá provázanost.

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.

Věděli jste, že nám můžete zasílat zprávičky? (Jen pro přihlášené.)

Komentáře: 3

Přehled komentářů

Zbyšek Překlepy
Martin Hassman Re: Překlepy
JS Pure fabrication
Zdroj: https://www.zdrojak.cz/?p=3673