Seriál: Jak se tvoří čistý kód aneb jak se vyvarovat paskvilům – 5. kapitola: Ještě záludnější příklad na zašpinění vrstvy

V předešlých článcích jsme si na jednoduchém příkladu vysvětlili jednu z nejčastějších chyb, kterou bychom mohli nazvat jako „zašpinění vnitřní vrstvy“. Podstatou této chyby je umístění evidované informace „příliš nízko“. Údaje o Čtenáři mají být ve Čtenáři (vyšší vrstva) a nikoliv v Osobě (nižší vrstva). Tento příklad má svou výhodu ve své jednoduchosti a průzračnosti (což je výhodou pro vysvětlení), ale musím podotknout, že situace bývají v praxi mnohem „záludnější“.

Uveďme si příklad na podobné téma. Zajímavá je statistika tohoto příkladu: Podle mého odhadu asi 90% vývojářů považuje chybné řešení tohoto příkladu za správné…

Představme si, že řešíme informační systém pro nějaký výrobní závod, konkrétně v tomto systému navrhujeme vcelku centrální modul Druhu zboží. Tento modul bude sloužit slangově řečeno jako tzv. „číselník Druhu zboží“, jinak řečeno pro jiné části systému se bude chovat jako nabízející se seznam Druhu zboží.  Okolní program jej bude používat tak, že pokud bude chtít dát okolní program nějaké své entitě vlastnost ve smyslu „tohoto Druhu zboží“, tak si na daný prvek ze seznamu prvků Druhu zboží ukáže směrovou asociaci ku jedné (Odkaz do seznamu, číselníková vazba). Například Řádek dokladu potřebuje údaj ve smyslu „tohoto Druhu zboží“, tak z Řádku dokladu vyvedeme referenci (neboli Odkaz do seznamu, slangově šipku s jedničkou) do Druhu zboží:

Pro zjednodušení příkladu, abychom si nemuseli hrát s měrnými jednotkami, baleními apod. daných druhů zboží, zvolme náš závod jako výrobnu zboží pouze na kusy a z podstaty věci nijak jinak. Implicitní a jedinou měrnou jednotkou je tedy počet kusů Druhu zboží.

Na základě prvních požadavků se zjistilo, že je třeba evidovat název druhu zboží a hmotnost daného prvku z tohoto druhu zboží Hmotnost je třeba evidovat proto, aby se mohlo hned určovat, jak se budou prvky tohoto Druhu zboží chovat na skladě, při vykládce a nakládce, manipulaci apod.

Zavedly se tedy dva atributy Druhu zboží takto:

A nyní přichází třetí požadavek: Od zákazníka zaznělo, že chtějí evidovat také aktuální počet kusů tohoto Druhu zboží na skladě. Pro jistotu se zeptáme, zda nechtějí evidovat pohyby (výdejku, dodejku anebo kolik se vložilo a kolik vydalo apod.). Odpověď zní: „Ne, potřebujeme evidovat pouze aktuální počet prvků daného Druhu zboží na skladě“.

Vývojář se tedy zamyslí nad slovním spojením „aktuální počet kusů daného Druhu zboží“, podívá se na model na předešlém obrázku, kde vidí velmi podobná slovní spojení: „název daného Druhu zboží“ a „hmotnost prvku daného Druhu zboží“ a zní mu to stejně.  Proto navrhne přidat další atribut do Druhu zboží takto:

První otázka zní: „Bude to fungovat podle přání zákazníka?“ Odpověď zní: „Ano.“

Druhá otázka zní: „A je to dobře?“ Odpověď zní: „Ne.“

Nevím jak u vás, ale z mých zkušeností příliš mnoho vývojářů na řešení zobrazeném na předešlém obrázku nevidí vůbec nic špatného (jak bylo zmíněno úvodem, mým odhadem až 90%).

Vidíte tam chybu a její důsledky? Zkuste ji odhalit, a pokud chcete, využijte diskusi pod článkem.

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


Uveřejněno

v

,

od

Značky:

Komentáře

2 komentáře: „Seriál: Jak se tvoří čistý kód aneb jak se vyvarovat paskvilům – 5. kapitola: Ještě záludnější příklad na zašpinění vrstvy“

  1. Jiří Punčochář avatar
    Jiří Punčochář

    Dobrý den,
    tak na první pohled je to špatně. Jednoduchá úvaha: počet ks na skladě není vlastnost zboží, tedy patří jinam. A na problém se narazí třeba, když si firma zřídí další sklad – obecně skladů může být více.

    1. RNDr. Ilja Kraval avatar

      Přesně tak, podrobněji viz další článek.

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *