JE TŘEBA DBÁT NA ANONYMITU KLIENTA NEBO NE? RNDr. Ilja Kraval, říjen 2008 http://www.objects.cz ÚVOD Začnu jedním zajímavým postřehem: Na našich školeních OOP a UML existují určitá témata, která při jejich probírání vždy vzbudí mezi účastníky poměrně vášnivou diskusi a to se opakuje takřka pravidelně s každým během školení. O jednom takovém zajímavém tématu bude i tento článek. JAK FUNGUJE ANONYMITA KLIENTA Hned jedna z prvních kapitol, která se ve školení OOP a UML probírá, se zabývá objektovým paradigmatem. Je to vcelku pochopitelné, vždyť se jedná se o základní princip objektové filosofie. Neznalost resp. zanedbávání tohoto principu vede k hrubým chybám při návrhu IS. Toto paradigma je postaveno na poměrně jednoduché myšlence, která se prolíná všemi úrovněmi abstrakce, tj. analýzou i technologickým designem. Tato myšlenka zní: Pokud jsou dva prvky systému v interakci, pak jeden prvek (tzv. klient) používá druhý prvek, přičemž to funguje tak, že jeden prvek nabízí službu a druhý tuto službu používá. Tato vlastnost interakce použití mezi prvky jako služba nabízená - služba použitá je všeobecná a platí tedy i pro modelování v UML. Objektové paradigma vede k trochu jiné představě, jak funguje interakce mezi prvky obecně. Například namísto formulace třída A dědí z třídy B bychom měli podle tohoto paradigmatu říci trochu složitěji: třída B nabízí službu dědění a třída A tuto službu používá. Nebo ukázka jiné situace: Funkce A volá funkci B se přeformuluje podle objektového paradigmatu na tuto větu: Funkce B nabízí službu zavolání a funkce A ji používá. Jednoduchá představa fungování tohoto paradigmatu je v obdobě nabízeného tlačítka služby na prvku, druhý prvek může toto tlačítko stisknout a tak použít danou službu.
strana 2 Je třeba zdůraznit, že uvedené paradigma platí i pro modelování a ve svém důsledku vede k tomu, že interakce zavedené v modelu jsou na sobě nezávislé a neovlivňují se navzájem, tj. jsou disjunktní. Trochu mi to jako bývalému fyzikovi připomíná bási vektorů. Například když třída A dědí z třídy B (viz raději předešlá přesnější formulace se službou) a přitom třída B má další interakce s jinými třídami (například i ona dědí anebo má asociaci na jinou třídu), tak pohled A končí na tlačítku B a další interakce B s někým jiným třída A nevidí. Paradigma sice vypadá jednoduše, ale v praxi bývá jeho použití mnohdy poměrně dost zašmodrchané a vede k bohatým a košatým diskusím, jak si ukážeme právě v tomto článku. DŮSLEDKY OBJEKTOVÉHO PARADIGMATU Existují dva hlavní důsledky objektového paradigmatu: 1. Klient vidí nabízenou službu (tlačítko služby) a nevidí implementaci (dráty za tlačítkem). Znamená to, že klient je odstíněn od implementace služby, říká se také, že služba má vlastnost zapouzdření. 2. Pro implementaci (dráty) je klient používající službu vždy anonym a mimo kontrolu dané implementace služby, říká se tomu anonymita klienta služby. První důsledek je všeobecně znám, bývá mnohdy vystižen slovy jako zapouzdření, enkapsulace apod. Nad druhým důsledkem však vznikají ony zmíněné diskuse a těm se budeme blíže věnovat. JAK FUNGUJE ANONYMITA KLIENTA Co vlastně značí bod 2. předešlé kapitoly? Dopředu upozorňuji, že se nejedná o žádnou akademickou diskusi, ale o velmi praktické závěry! Anonymitu klienta bychom mohli jednoduše vystihnout slovy: Implementace služby (tj. vnitřek služby objektu) nikdy neví, kdo stiskne tlačítko a nikdy nemá v moci, co se děje venku. Vyplývá z toho jeden důležitý a praktický závěr: Při návrhu objektu se nikdy nemůžeme spolehnout na klienta, jinak řečeno kdoví, jaký pobuda tam bude a co bude dělat! Samozřejmě, jak bylo řečeno úvodu, důsledek objektového paradigmatu anonymita klienta vyplývá přímo z principu opětovné použitelnosti: Jestliže nabízíte svůj prvek k tomu, aby byl strana 2
strana 3 opětovně použit (například vystavením do knihovny kódu), tak jej nabízíte komukoliv, kdo jej může použít. Slovo komukoliv je zde synonymum pro anonymního klienta. Pokud jsme stále nepochopili princip anonymity klienta v objektové filosofii do všech důsledků, uvedu jedno velmi názorné vysvětlení (které se mi líbí i svou určitou dávkou humoru). V jedné firmě v Čechách jsem při školení vysvětloval anonymitu klienta. Chvíli poslouchali a pak se zvedla jedna ruka a kolega povídá: U nás ve firmě platí jeden vyšší princip, než je anonymita klienta! Ptám se překvapeně: A jaký? Odpověděl mi s úsměvem: Německý ordnung! Když uviděl můj udivený pohled, dodal: Hned vysvětlím. Jsme dceřinou společností německé firmy. Když přijel jeden z šéfů z Německa a díval se, jak testujeme, tak se hrozně divil. Například jsme testovali, že zadaná hodnota v poli nesmí být nula a tedy že systém tuto nulu dál nepustí. Němec na to povídá: A proč to testujete? Odpověděli jsme: Přece když obsluha zadá nulu, tak to systém nesmí dál pustit! A Němec na to: Ale přece tady v manuálu stojí, že obsluha nesmí zadat nulu! A my na to: No jo, ale když obsluha zadá nulu A Němec na to: Ale přece obsluha nesmí zadat nulu, to neexistuje, to si nedovedu ani představit, že by obsluha zadala nulu, když má pokyn z manuálu nezadávat nulu! Ano, dotyčný dobře vystihl jedinou možnost, jak ignorovat důsledky anonymity klienta: Vydejme metodický pokyn pro klienta objektu! Platí jednoduché pravidlo: Porušování anonymity klienta předpokládá vydávat metodické pokyny pro prostor klienta, tedy pro okolí objektu! Poznámka bokem: Jinak co se týče tohoto příkladu, osobně jsem přesvědčen, že česká obsluha na rozdíl od německé první, co by zkusila, by bylo, zda nula projde Uvedený pěkný příklad nám také velmi názorně poukazuje na praktický důsledek anonymity klienta, a tím je nutnost přemýšlet nad tzv. blbovzdorností objektů. Anonymita klienta pro každý objekt nebo prvek (tedy nejenom systém) znamená, že se nikdy neopíráme o německý ordnung v prostoru klienta! Toto platí například v objektovém programování při návrhu objektů: Jestliže odevzdáváte do knihovny objektovou třídu k použití, tak se nikdy nesmíte spoléhat na to, co bude muset dělat klient, aby náš objekt z této třídy správně a logicky fungoval! Znamená to, že při návrhu objektu nejde jen a pouze o rozdělení kódu na dvě části: Vnitřek a vnějšek objektu, tj. nejde jen o rozmístění kódu co je venku a co uvnitř! Objektové paradigma a následná anonymita klienta vedou k tomu, že vnitřek objektu je uzavřený stabilní svět s konzistentními stavy odpovídajícími tomu, co u objektu postupně voláme a strana 3
strana 4 tento svět je schopen relevantně reagovat na jakékoliv chování okolí a nespoléhá se na logiku tohoto okolí. ÚPLNÁ PROGRAMÁTORSKÁ DOKUMENTACE OBJEKTŮ Anonymita klienta vede k jednomu zajímavému závěru ohledně dokumentace objektu (v programování přesněji třídy, která objekty stejných vlastností rodí): Jestliže odevzdáváte programátorskou dokumentaci v OOP, tak tato dokumentace u objektově čistě navrženého objektu je z hlediska objektu úplná, když popíšete služby (tj. interface) a implementaci a šlus. V čistém návrhu OOP k tomu nemusíte popisovat nic víc z okolí! Naopak, pokud musíte dodat navíc u dokumentace objektu, že klient musí / nesmí něco dělat a tedy logika je i u klienta (jinak řečeno musíte proto vydat metodiku pro klienta), tak je to z hlediska čistého OOP špatně. Pozor, neznamená to, že objekt na vše reaguje tak říkajíc příznivě, v některých případech použití služby vyhazuje výjimky! Důležité je, že o této výjimce se dočtete v dokumentaci u metod objektu. DISKUSE NAD ANONYMITOU KLIENTA A JEJÍ PORUŠENÍM V čem spočívá problém mnohých programátorů a co je podstatou diskuse na školeních? Odpověď je jednoduchá: Požadavek na blbovzdornost se jeví jako hodně maximalistický! Dotazy v těchto diskuzích pak znějí takto: To máme u každého objektu řešit a ošetřovat například vstupní parametry? Co když víme, že tento objekt bude vždy volán někým, kdo to ošetří za něj? To máme ošetřit stavy při posloupnosti volání metod, ke kterým díky průběhu programu nikdy nemůže dojít jinak, než v požadovaném pořadí? To má každá vrstva systému ošetřovat blbovzdornost, třebas onu zmíněnou německou nulu na vstupu? Nejdřív v GUI, potom ve střední vrstvě - objektech (JAVA, C#) a ještě v databázi? Zajímavé otázky! Dovedli byste na ně odpovědět? Zkuste! Než tak učiníte, přečtěte si ještě příklady, tam najdete návod, jak a kde se ptát a odpovídat! strana 4
strana 5 PŘÍKLADY NA VYUŽITÍ ZNALOSTI O ANONYMITĚ KLIENTA Zkuste se zamyslet nad následujícími příklady, můžete se případně ptát nebo nabízet řešení, navíc můžete odpovědět na otázky v předešlé kapitole! Využijte k tomu diskusi k článku 54 na našem diskusním serveru! PŘÍKLAD PRVNÍ Jak se projeví anonymita klienta v případě, že víme, že u objektu před zavoláním operace B()musí být nejdříve zavolána operace A()? PŘÍKLAD DRUHÝ Máme vyvinout systém pro realizaci elektronických plateb za služby, přičemž existují tyto tři subjekty: Náš platební systém, označme jej SYS, dále existuje systém X na webu poskytující službu (například lístky do kina) a dále existuje zákazník Z žádající službu a platící do našeho systému. Systém X je s námi propojen například přes linku https (on je klient, my server), může nás elektronicky zavolat a dostat odpověď. Postup poskytnutí služby je následující: 1. Zákazník Z si objednává službu u X přes web. 2. Zákazník zaplatí za tuto službu přes nějaký kanál v našem SYS (například mobilem nebo jinak) a tím dostane službu od X k dispozici. Platba musí být samozřejmě správně identifikována zadaným kódem od zákazníka. Zákazník opíše kód z webu subjektu X a posílá ho jako součást platby. 3. Jednou měsíčně se vyrovnáme se všemi subjekty S tak, že jim pošleme peníze za zaplacené služby ponížené o marži (např. 0,5%). Využije se identifikace platby podle kódu v bodě 2 Z obchodního oddělení zazněl požadavek: Pokud zákazník Z zadá chybný kód pro rozlišení platby, anebo subjekt X poskytne na webu chybný kód, tak platba nesmí projít, nechceme vracet peníze! strana 5
strana 6 WWW server Náš platební systém SYS objedná (dostane kód) zaplatí (použije kód) Zákazník Vyřešte celkovou logiku chodu podniku (business process) jako slovní scénář od objednání po zaplacení tak, aby byl požadavek na odmítnutí platby zohledněn. Těším se a znovu připomínám: Náš diskusní server je zde! Konec článku strana 6