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

Odebírat
Upozornit na
guest
1 Komentář
Nejstarší
Nejnovější Nejvíce hlasů
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á.“

:)

Proč vám model napíše Python, i když jste si řekli o Rust

AI
Komentáře: 0
Výkonnostní propast mezi Pythonem a ostatními jazyky se za poslední rok a půl skoro zavřela. Dnešní modely zvládají Rust i Go srovnatelně dobře. Když jim ale volbu necháte, sáhnou stejně po Pythonu. A u knihoven je to ještě výraznější: mezi funkčně srovnatelnými balíčky je až 84procentní rozdíl v kvalitě generovaného kódu. Proč to tak je a co s tím.

WP2Shell: Kritická hrozba pro samotné jádro WordPressu. Útočníci mohou získat kontrolu nad webem

Zranitelnost ve WordPressu není žádná novinka. Kdo provozuje weby postavené na této platformě, ví, že bezpečnostní záplaty chodí prakticky pořád. O to větší pozornost by měla vzbudit chyba, u které nic z toho neplatí. A přesně takový je případ zranitelnosti, která dostala přezdívku wp2shell. potřeb. Zranitelný kontaktní formulář, děravý e-shopový plugin, opomenutá kontrola oprávnění v nějaké obskurní rozšiřující knihovně – to je denní chleba každého, kdo sleduje bezpečnostní feedy. Zpráva „nová chyba ve WordPress pluginu“ má tak nízkou informační hodnotu, že ji většina lidí přejde bez mrknutí oka.

Mýtus jedné aplikace: proč PWA nenahradí vývoj pro každou platformu

PWA mohou webu přidat ikonu na ploše, fungování bez připojení, notifikace a některé systémové funkce. Nejsou ale cestou k jednomu klientu pro všechny platformy. Vyplatí se tam, kde se lidé k webu vracejí a ocení okamžitý vstup z odkazu. Jakmile aplikace musí spolehlivě běžet na pozadí nebo fungovat stejně na každém zařízení, bývá vhodnější nativní řešení.