V předešlém článku jsme předložili model se studenty, zaměstnanci, osobami, zaznělo zadání ve smyslu „evidujeme půjčování knih“ a otázka byla formulována takto:
“Kam umístíme všechny požadované údaje o půjčování – zápůjčky, číslo průkazu, atd., v tomto modelu? Do studenta, do zaměstnance anebo do osoby, když i student i zaměstnanec si mohou půjčovat knihy?”
V tomto článku si ukážeme analyticky čisté a správné řešení.
Navážeme na již předložené řešení, kde jsme zavedli analytické třídy Student, Zaměstnanec a Osoba takto:
Pro nalezení správného řešení nemusíme chodit příliš daleko, předešlý obrázek jej přímo nabízí:
Evidovaný Student nese potřebné údaje studenta, tedy toho, kdo studuje, podobně evidovaný Zaměstnanec nese potřebné údaje zaměstnance, tedy toho, kdo je zaměstnán a takto tedy pokračujme dále: Podle stejného mechanismu bude existovat další analytická třída, která ponese údaje toho, kdo si půjčuje knihy. Mechanismus vazby na Osobu bude úplně stejný, pouze musíme najít správný název pro tuto třídu.
Stojí za zmínku, že v našich školeních se v tomto cvičení od účastníků objevují zajímavé návrhy pro název této třídy, například „Klient knihovny“, „Knihovna“, „Zápůjčky“, „Čtenářský průkaz“ atd. To vše není přesné a správné, protože to vše není název pro evidovaný prvek, který nese údaje toho, kdo si půjčuje knihy. Považuji za nejlepší název této třídy „Čtenář“ (protože tak je chápán onen „Klient knihovny“).
Zavedení nové třídy Čtenář tedy podle tohoto mechanismu bude vypadat takto:
Je zřejmé, že existují celkem 4 oblasti budoucího kódu, které mohou být rozděleny fyzicky až do 4 modulů (pokud bude třeba): Modul osob (centrální), Modul studentů, Modul zaměstnanců a Modul čtenářů.
Poznámka: Tento model lze ještě dále vylepšit dalším krokem: Zavede se abstraktní třída Role Osoby, která ponese odkaz do Osoby, a uvedené tři konkrétní (tj. neabstraktní) třídy Student, Zaměstnanec a Čtenář se stanou potomky této třídy, takže tento odkaz podědí. Tento vylepšený model má o něco vyšší re-use, protože spousta věcí se naprogramuje vůči horní abstraktní třídě Role osoby. Toto řešení i s technologickým návrhem si ukážeme v některém z příštích článků.
Jaké jsou nejčastější chyby při hledání pozice informace v tomto příkladu? Nejčastějším případem je zašpinění vnitřní vrstvy Osoby údaji Čtenáře. Tyto údaje Čtenáře do Osoby nepatří. Jedná se o typický záporný bonus linkování, protože každý, kdo si přilinkuje Modul osob, dostane také Čtenáře, což je zárodek molochálního (nedělitelného) systému. Uvedu příklad: Představme si, že dojde ke změně ve struktuře Čtenáře (a tyto údaje jsou chybně umístěny v Osobě). Tyto změny se musí samozřejmě přeprogramovat a je zřejmé, že se tato změna týká všech, kdo používají Modul osob. Takže teoreticky vzato by se měly tyto části (tj. Modul studentů, Modul Zaměstnanců) po dané změně také otestovat. Nedej bože, aby se ve Čtenáři, který je umístěn do Osoby, vyskytla chyba a Modul osob díky tomu vykazoval nějaké chyby nebo dokonce padal. Poslouchejme dobře tuto větu: „nechodí nám studenti, protože máme chybu ve čtenářích“. Je to věta proti zdravému selskému rozumu.
Jak uvedená chyba zašpinění vnitřní vrstvy vlastně vzniká? Laik si může dovolit nepřesné formulace, analytik nikoliv. Například věta „u evidované osoby si budeme evidovat údaje o půjčení knih“ není přesná, je to tzv. „laická zkratka“, na kterou si analytik musí dát pozor. Když se podíváte na model, tak přesnější věta zní takto: „u evidovaného čtenáře, který je touto osobou, si budeme evidovat údaje o půjčení knih“.
Mimochodem formulace z diskuse ve smyslu „údaje umístíme do samostatného modulu (Knihovna), který bude mít vazbu na popisovaný modul evidence studentů a zaměstnanců“ není úplně přesná, protože Modul knihovny nebude mít vazbu na Modul evidence studentů a zaměstnanců, ale pouze na vnitřní Modul osob (a nic víc).
Uvedený příklad je vysoce názorný (což je samozřejmě výhodou u příkladu), ale musím upozornit, že mnohdy je nalezení čistého řešení mnohem náročnější a laické zkratky jsou často velice záludné, což si uvedeme v dalším příkladu příště.
Pokračování příště
Napsat komentář