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

Zdroják » Různé » GRASP – 3 – Low coupling

GRASP – 3 – Low coupling

Články Různé

V tomto díle o návrhových principech GRASP (General Responsibility Assignment Software Patterns) se budeme zabývat principem Low coupling – Slabá provázanost. Jde o další hodnotící princip sloužící k porovnávání různých zvažovaných možností návrhu, který doplňuje princip High cohesion – Vysoká soudržnost z minulého dílu o pohled z jiného úhlu.

Low coupling – Slabá provázanost

Provázanost (coupling)  – je míra toho, jak moc je jeden prvek (třída, subsystém, modul, …) propojen s dalšími prvky, tedy zda o nich má informace nebo na ně spoléhá.  Prvky s vysokou provázaností závisí na velkém množství dalších prvků systému a naopak. Pokud jsou prvky provázané, změny jednoho z nich ovlivňují i druhý a je obtížné je znovu použít odděleně.

Princip Low coupling nám říká:

Zodpovědnosti přiřazujte tak, aby provázanost zůstala co nejmenší.

Kromě toho, že kvůli závislosti mohou změny v provázaném prvku způsobit nutnost lokálních změn, má silná provázanost řadu dalších nevýhod. Pokud je prvek silně provázán s dalšími prvky, je obtížné jej pochopit v izolaci. Abychom porozuměli jeho funkci, musíme pochopit prvky, se kterými je provázán, a jejich vzájemné vztahy.

Je také zhoršena znovupoužitelnost. Pokud chceme silně provázaný prvek použít v jiném kontextu, je nutné převzít nebo nahradit všechny prvky, se kterými je provázán. Čím více takových prvků je, tím více úsilí jeho znovupoužití vyžaduje.

Zdroje a typy provázanosti

 Craig Larman uvádí jako typické zdroje provázanosti tříd A a B:

  • A má atribut odkazující na typ B
  • A volá službu/metodu typu B
  • Parametr nebo návratová hodnota služby/metody typu A je typu B
  • Typ A je potomkem typu B
  • Typ A implementuje rozhraní B

Glenford J. Myers ve své knize Reliable software through composite design zavedl následující klasifikaci provázanosti (od nejsilnější po nejslabší). Tato klasifikace se původně vztahovala na provázanost modulů v procedurálních jazycích, ale lze ji analogicky použít i pro objektově orientovaný návrh.

Content coupling

Označovaná také jako patologická provázanost (Pathological coupling); vyskytuje se v případech, kdy jeden prvek závisí na interních datech jiného prvku. Pokud dojde ve změně způsobu, jakým tento prvek se svými interními daty pracuje, je nutná změna i v provázaných prvcích.  V objektově orientovaných jazycích je tento typ provázanosti při používání zapouzdření obtížnější vytvořit než v jazycích nižší úrovně. Prvky by musely záměrně nebo omylem umožnit manipulaci se svými interními prvky nebo by tato omezení musel být nějak obcházena (například použitím reflections).

Common coupling

Označována také jako Global coupling se vyskytuje v případě, že dva prvky sdílejí nějaká společná globální data. A to ať již v podobě globálních proměnných, stavu systému nebo například nesprávným využíváním návrhového vzoru Singleton. Typickým způsobem, v jakém se tento typ provázanosti vyskytuje v objektově orientovaných systémech, jsou veřejně dostupné proměnné objektů, se kterými pracuje řada dalších objektů.

Změna ve sdílených globálních datech vyžaduje změnu všech prvků, které je používaly. Navíc chyba jednoho modulu při práci s globálními daty může snadno zanést následné chyby do práce dalších modulů.

External coupling

Dva prvky používají stejný datový formát, komunikační protokol nebo rozhraní k nějakému externímu zařízení či službě.

Control coupling

Jeden prvek řídí interní fungování jiného prvku tím, že mu předává informace o tom, co má dělat. Typickým příkladem tohoto typu provázanosti jsou příznaky (flags) ovlivňující výsledek operací. Například metoda, které v parametru předáme informaci o tom, v jaké podobě vrátit výsledek.  Dalším příkladem jsou návratové hodnoty, které určují, jak by mělo pokračovat jejich zpracování (chybové kódy v návratových hodnotách).

Stamp coupling (Data-structured coupling)

Více prvků používá stejnou datovou strukturu, z níž každý využívá jen určitou část. Příkladem je předávání celého záznamu do metody, která z něj používá pouze jednu položku.

S tímto způsobem provázanosti se pojí pravidlo: „Nikdy nepředávejte rozsáhlou datovou strukturu, pokud potřebujete použít jen pár jejích položek.“

Jedná se o slabší formu provázanosti, kterou je občas výhodné porušit kvůli zjednodušení rozhraní prvků.

Data coupling

Prvky sdílejí data například prostřednictvím parametrů metod a jejich návratových hodnot a předávána jsou pouze data, která jsou využita. V ideálním případě by všechny provázanosti měly mít tuto podobu.

Žádná provázanost

Extrémním případem nízké provázanosti je žádná provázanost. To je ale očividně nesmysl. Objektově orientovaný systém je tvořen množinou vzájemně komunikujících objektů, mezi kterými tedy musí existovat nějaké vazby.

Pozor na extrémy

Pokud by byl princip nízké provázanosti aplikován do extrému, vedl by ke špatnému návrhu v podobě několika přerostlých, nesoudržných a složitých objektů. Určitá míra provázanosti mezi třídami je normální a nezbytná. Měli bychom se vyhnout zbytečnému provázání, ale nesmíme to přehánět.

Také provázanost s neměnnými nebo standardními prvky (jako například standardní systémové knihovny) není problémem, který by bylo potřeba řešit.  Problémem totiž není samotná provázanost, ale především provázanost s nestabilními prvky, které se často měníPokud je prvek neměnný, odpadá hlavní nevýhoda provázanosti – nutnost reagovat na změny jiných prvků. Tento princip tedy v určitém smyslu vychází z principu Protected variantions – Chráněné změny.

Neměli bychom investovat čas do snížení provázanosti s prvky, u kterých je nepravděpodobné, že se někdy nezmění. Místo toho bychom se měli zaměřit na provázanost s prvky, které jsou nestabilní a které se nejspíše budou dále vyvíjet.

V praxi není možné používat princip nízké provázanosti v izolaci od dalších principů jako je High cohesion a Information Expert (bude předmětem jednoho dalšího dílu). Jde pouze o jeden z faktorů, který by měl být zvažován.

Závěr

Principy High cohesion a  Low coupling  patří mezi nejzákladnější principy návrhu software. Larry Constantine, jeden ze zakladatelů strukturovaného programování, je již v 60 letech označil jako nejkritičtější principy. Tyto principy bychom tedy měli mít na mysli při zvažování všech návrhových rozhodnutí.

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

V dalším díle se podíváme na principy Information Expert – informační expert a Creator – Tvůrce, které představují základní principy při výběru objektů pro přidělení zodpovědnosti podle GRASP.

Zdroje a další informace

Komentáře

Subscribe
Upozornit na
guest
1 Komentář
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
jistr

„Neměli bychom investovat čas do snížení provázanosti s prvky, u kterých je nepravděpodobné, že se někdy nezmění.“

Asi bylo myšleno „[…] s prvky, u kterých je nepravděpodobné, že se někdy změní.“

A možná bych to raději zjednodušil na „[…] s prvky, jejichž změna je nepravděpodobná.“

:)

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.