V knize Analytické modelování pomocí UML v praxi (volně ke stažení zde) je uveden jeden názorný příklad vysvětlující určité záludnosti objektového paradigmatu, viz kaptiola 1.3.2, strana 12. Na tomto příkladu si uvedeme jeden z nepříjemných důsledků nedodržování čistoty kódu včetně zajímavé hádanky, která v knize není uvedena.
Stručně shrnuto, v tomto příkladu se pro evidenci studentů a zaměstnanců vyžaduje zavést v evidenci (unikátní) rodné číslo, pomocí kterého budeme evidované studenty resp. zaměstnance rozlišovat proto, abychom jednoho studenta nezaevidovali dvakrát (resp. totéž u zaměstnance).
Příklad v knize odpovídá na otázku “obsahuje evidovaný student (resp. evidovaný zaměstnanec) rodné číslo, ano nebo ne?”. Laická úvaha vede ke zdánlivému rozporu: Na jedné straně evidovaný student rodné číslo obsahovat musí, protože na základě něj se evidované instance studentů rozlišují. Na straně druhé, protože student může být zaměstnancem (resp. naopak), tak pokud student potažmo student obsahuje rodné číslo, tak tato úvaha “ano, obsahuje” vede logicky ke zdvojení rodných čísel.
style=”text-align: justify;”>Návodem pro správnou odpověď “ano/ne” je tzv. objektové paradigma, které zavádí vnější a vnitřní pohled, z toho důvodu je správnou odpovědí “ano i ne, záleží na úhlu pohledu”: Z vnějšího pohledu jej “obsahuje” (ale lepší výraz než “obsahuje” je “umí jej nějak vydat”), z vnitřního pohledu nikoliv, protože deleguje požadavek pro vydání rodného čísla na prvek Osoba, takže jej v sobě (jako atribut) nemá:
Obrázek 1: Vztah Student versus Osoba resp. Zaměstnanec versus Osoba
Poznámka: Bližší vysvětlení viz uvedená kniha.
Na obrázku je mimochodem zřetelně patrné nasazení opětovné použitelnosti. Pokud technolog dodrží zadání, pak ta část kódu, která bude naprogramována “nad studenty”, použije tu část kódu, která bude naprogramována “nad osobami”. Například obrazovka pro založení nového studenta využije naprogramovaný prvek pro výběr osoby, tento prvek bude implementován v modulu osob a bude opětovně použit i v obrazovce pro založení zaměstnance. (Poznámka: Předešlá věta má přímý vztah k interakci include v Use Case Diagramu, viz články o include a extend na našem serveru).
Nyní k samotnému problému našeho článku, což již není v knize uvedeno.
Mimochodem uvádím tento příklad při pokračování výkladu jako jeden z mnoha jiných na školeních (prezenční, firemní, distanční) a proto mohu na konci článku uvést velmi zajímavou statistiku.
Představme si, že budoucí uživatel (alias Product Owner, konzultant) se vysloví takto: “My tam máme knihovnu a chceme si evidovat, jak si ty osoby budou půjčovat knihy, tj. zápůjčky knih, číslo průkazu atd.”
Zeptáme se: “Mohou si studenti půjčovat knihy?”
“Jistě.”
“A zaměstnanci taky, že?”
“Samozřejmě.”
Nyní máme před sebou již hotový model se studenty, zaměstnanci, osobami (viz obrázek 1) a ptáme se:
“Kam tedy umístíme všechny ty údaje jako 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?”
Nebudu zde nyní zveřejňovat správnou odpověď, jen jako nápovědu uvedu, že statisticky vzato asi tak 75% vývojářů odpovídá chybně.
Pokud chcete, dejte do diskuse váš návrh, nebudu jej však jako admin zveřejňovat hned a okamžitě, aby se mohli případně vyjádřit ostatní. Případně můžete poslat mail s vaším návrhem na adresu objects@objects.cz.
Pokračování následuje.
Prosperující SW firma hledá analytiky a JAVA programátory v okolí Hradce Králové
V případě zájmu pište na e-mail objects@object.cz
Vytvořil bych interface, který by implementovali jak student tak zaměstnanec nebo nějaká další osoba, které umožním přístup do knihovny. Poté bych si v app pomocí toho interface vyhledal všechny, kteří ten interface implementují a pracoval s tím.
Do samostatného modulu (Knihovna), který bude mít vazbu na popisovaný modul evidence studentů a zaměstnanců.
A co když si v budoucnu bude půjčovat třeba organizace nebo oddělení nebo (agilní :-) ) tým…? Takže dávám hlas modulům. Modul zaměstnanců jako jeden z možných dlužníků…
Když to bude zaměstnanec, tak do zaměstnance a když student, tak do studenta. V osobě to, dle mého názoru, nemá co dělat.
bohužel, řešení, které předkládáte, má základní chybu v “META posunu”.
Model tříd a následně kód je v tzv. statickém prostoru aplikace, tj. je to věc natvrdo, kde co bude umístěno.
Vy ale popisujete dynamickou věc (“pokud to bude zaměstnanec” atd.). Jenže “pokud to bude zaměstnanec”, tak v něm už musí být staticky “políčka” pro čtenáře připravené. Takže v obou již musí být připravené struktury pro čtenáře, což je logicky špatně. Máte sice pravdu, že do Osoby to nepatří, ale nepatří to ani do Zaměstnance a ani Studenta.
(Viz další článek: Stejným mechanismem, jako jsou zavedeny entity Student a Zaměstnanec se zavede další, Čtenář. Dokonce je tam schována Generalizace).