Metamorfózy a migrace návrhových vzorů
Je vzrušující pozorovat, jak na svém počátku amorfní a abstraktní vzor nabývá svébytného a ostře ohraničeného tvaru pri svém dospívání, když je adoptován různými technologiemi. Zasazením vzoru do jednoho vývojového prostředí a kontextu se může zdát, že je na univerzálnost svého použití aspirující smysl vzoru zastřen a překryt dominantním zaměřením a převládajícími výrazovými prostředky jedné technologie. Každý dobrý návrhový vzor se ale svojí konkretizací v jedné nebo i více technologiích nevyčerpává, ale je připraven vymanit se ze sevření každé technologie a při změně IT paradigmatu znovu nabídnout svoji plnou formativní potenci pro nové postupy, pravidla a vazby ve vývoji. Když se mění technologie, programovací jazyky nebo celé zažité programátorské návyky (strukturální versus objektové programování), tak esence kvalitního návrhového vzoru není dotčena a jeho abstraktní smysl začne být jen artikulován výrazovými prostředky žezlo přebírajícího paradigmatu a z něj vyplývajícího znalostního a pojmového horizontu. Dobrý návrhový vzor participuje na tvorbě struktur nového paradigmatu a současně je nově vznikajícími strukturami přetavován ve svou jinou, parciální a dočasnou formu.
Když nechcete, aby vaše znalosti beznadějně zastaraly za pár měsíců, nebazírujte na zvládnutí programovacích jazyků, vývojových prostředí nebo frameworků, ale stavte své znalosti na návrhových vzorech. .Net Framework nebo J2EE jsem se naučil tak, že jsem se za jednotlivými knihovnami nesnažil vidět deprimující změť tříd a metod, ale harmonii návrhových vzorů.
Jak se projevují migrace a proměny vzorů?
Vezměme si za příklad vzor Asynchronous Completion Token (ACT) popsaný v knize Patterns Oriented Software Architecture (autor Frank Buschmann a kolektiv). Tento vzor popisuje, jak dosáhneme efektivního a na zdroje počítače nenáročného zpracování odpovědí z více asynchronních požadavků. ACT je objekt (v obecném slova smyslu), který unikátně identifikuje každý asynchronní požadavek a slouží k výběru správného zpracovatele odpovědí. Participanti vzory jsou tři - iniciátor asynchronního požadavku, služba, která je volána a ACT pro korelaci požadavků a odpovědí.
V .NET je ACT vzor transformován do speciálního vzoru pro asynchronní volání, kdy je zavedena formální konvence, že asynchronní metody jsou prefixovány slovy Begin (začátek požadavku) a End (Konec požadavku), Každý delegát nabízí metody Begin a End, jejichž posledním parametrem je zase dle konvence jakýkoli objekt, který pak v systému hraje roli ACT. ACT neslouží ale k výběru primárního zpracovatele asynchronní odpovědi, protože ten je na začátku asynchronního volání determinován předposledním parametrem, jímž je delegát AsyncCallBack ukazující na metodu s kompatibilní signaturou. Předaný ACT ale může být klíčem k dynamickému určení sekundárního zpracovatele a/nebo je objektem pro přenos stavových informací.
.Net si tedy ACT vzor přizpůsobil k obrazu svému a vybral si jen některé jeho myšlenky.
ACT se také uplatňuje v SOA - v architektuře založené na službách, které si mezi sebou asynchronně vyměňují tisíce zpráv denně, potřebujeme prostředek pro korelaci zpráv-požadavků a návazných zpráv-odpovědí. V SOA je uplatňován návrhový vzor s názvem Correlation Identifier - v hlavičce zprávy je uložen jednoznačný identifikátor požadavku, který je v hlavičce odpovědi zaslán zpět odesílateli. Jsme v SOA a stále pracujeme se starým dobrým ACT vzorem, jen místo delegátů mluvíme o zprávách, dokumentech a hlavičkách s ACT informací.
Vzor Correlation identifier (a ACT) je dále rozpracováván ve specifikacích pro jednotlivé technologie. Když budeme mít SOA založenou na webových službách, setkáme se s normovaným ACT ve standardu ws:addressing, kde je stanovena a přijata konvence, že ACT musí odesílatel poslat v hlavičce nazvané MessageId a kdy je vyžadováno, aby hlavičku uvedl, a odesílatel je povinen hodnotu z MessageId poslat v hlavičce odpovědi s názvem RelatesTo.
Až skončí éra SOA, webových služeb, .Net Frameworku a přijde jiná, úžasnější, oslnivější a zase skoro dokonalá technologie, na které se bude hlavně dobře vydělávat,;) nepřežijí dílčí implementace ACT v těchto prostředích, ale můžeme si být skoro jisti, že vzor ACT jako bájný Fénix vstane omlazený z popela, změní svůj vnější vzhled, aby byl "in", ale jeho podstata zůstane beze změny, dokud budou existovat asynchronní volání.
Monday, October 04, 2004 9:54:00 PM (Central Europe Daylight Time, UTC+02:00) 
Analytické drobky
Synchronizace stavových automatů. Rozumíte návrhovému vzoru Mediator?
Návrhový vzor Mediator zamezuje těsným vztahům mezi objekty zavedením prostředníka (mediatora), který jejich interakci zapouzdří. Tak praví strohá, ale výstižná definice. Řečeno jinak, Mediator snižuje přímé i nepřímé zatížení třídy jinými třídami.
Vzor Mediator je většinou vykládán na příkladu interakce komponent v uživatelském rozhraní, které spolu komunikují přes prostředníka, jímž je formulář. Listbox se seznamem zemí neví nic o Listboxu se sezamem měst - po výběru jiné země je vyvolána událostní procedura formuláře, v níž je kód pro naplnění druhého Listboxu městy ve vybrané zemi. Každý ovládací prvek spolupracuje jen s formulářem, který notifikuje o změně ve svých vlastnostech, a na formuláří je kód propagující změny do dalších prvků. Na způsobu chování nezáleží, formulář může být u prvku zaregistrován jako Observer (v terminologii jazyka JAVA Listener), jehož metoda je zavolána po změně stavu prvku, nebo v .NET zaregistrujeme u ovládacího prvku delegáta s obslužnou metodou, jejíž signatura se shoduje se signaturou události. Komplexního chování prezentační vrstvy není dosaženo přímou spoluprací mnoha objektů, ale zavedením inteligentní mezivrstvy, která je recipientem heterogenních notifikačních zpráv objektů a současně autorem a distributorem nových aktualizačních zpráv pro další objekty, jež po jejich přijetí změní svůj stav a přitom mohou prostředníkovi odeslat další notifikační zprávy. Zdůraznil bych, že prostředník je autorem zpráv, takže informaci o notifikaci nemusí jen přeposlat, ale také dokáže argumenty původní notifikační zprávy před odesláním kreativně pozměnit, filtrovat, anebo dokonce rozešle události v jiném pořadí. Jak uvidíme, všechny tyto charakteristiky jsou klíčové pro mediatora koordinujícího synchronizaci stavových automatů business objektů.
Kdyby ovládací prvky mezi sebou komunikovaly přímo, tak i jednoduchá změna chování prezentační vrstvy roztočí spirálu sisyfovského dohledávání a ošetřování dopadů změny v kódu všech prvků.
Použití vzoru Mediator ale není omezeno na prezentační vrstvu a jeho kvality se plně projeví až při řízení složité interakce stavových automatů tříd v business vrstvě.
Představte si systém pro nábor zaměstnanců na různé pozice. V systému jsou evidovány nabízené pracovní pozice a uchazeči. Když uchazeč projeví zájem o pozici, je vytvořen nový objekt pro relaci mezi uchazečem a pozicí, v němž jsou uložena data o průběhu procesu výběru jednoho uchazeče. Platí pravidlo, že v jednom okamžiku může být Uchazeč přiřazen jen k jedné Pozici. Pozice, Uchazeč i Relace mají své stavové diagramy. Uveďme si příklady stavů.
Pozice může být ve stavu:
Nová - Zahájení životního cyklu pracovní pozice.
Přiřazen alespoň jeden uchazeč – O pozici se zajímá alespoň jeden uchazeč. Tento stav je důležitý pro manažery, kteří jsou odpovědni za obsazení pozice a zajímá je, zda například týden po vypsání místa je o pozici zájem, nebo je třeba investovat více peněz do propagace.
Přijat alespoň jeden uchazeč – K pozici se může vázat více volných míst, tento stav manažery náboru informuje, že již byl vybrán alespoň jeden vhodný zaměstnanec.
Obsazená – Pozice byla obsazena. Počet nabízených míst je roven počtu přijatých uchazečů.
Zrušená – Pozice byla zrušena. Pozici je možné kdykoli zrušit, což značí, že k ní již není možné dále přiřadit uchazeče a přiřazení uchazeči, kteří ještě nebyli přijati, jsou ihned odmítnuti.
Stavy uchazeče
Nový – Založení uchazeče.
Zajímá se o pozici –Uchazeč byl přiřazen k pozici a prochází různými zkouškami. Nelze mu přiřadit další pozici.
Přijat – Uchazeč byl přijat na pozici. Pozice musí být notifikována o přijetí uchazeče.
Odmítnut – Uchazeč byl odmítnut, to znamená, že je ho možné přiřadit k jiné pozici.
Propuštěn – Uchazeč (zaměstnanec) byl propuštěn. Opět ho je možné přiřadit k jiné pozici.
Zrušen – Uchazeč byl zrušen. Zrušit lze jen uchazeče ve stavu Nový, Odmítnutý a Propuštěný. Je nutné notifikovat aktivní relaci mezi Uchazečem a Pozicí.
Stavy relace mezi uchazečem a pozicí
Nová
– Nová relace mezi uchazečem a pozicí založena. Je nutné notifikovat pozici i uchazeče, že byla mezi nimi vytvořena relace.
Uchazeč prošel psychotesty – Uchazeč úspěšně prošel psychotesty.
Uchazeč odmítnut po psychotestech –Uchazeč neprošel psychotesty, notifikovat pozici a uchazeče o odmítnutí.
Uchazeč splnil všechny požadavky – Notifikovat pozici o přijetí dalšího uchazeče, notifikovat uchazeče.
Zrušena – Došlo ke zrušení relace, důvodem může být to, že uchazeč o pozici ztrati zájem nebo je zrušena pozice. Notifikovat uchazeče a pozici o zrušení.
Jde sice jen o reprezentativní množinu tříd a jejich stavů, ale i mezi takto malým počtem tříd existuje poměrně složitá spolupráce.
Například při zrušení pozice musejí být notifikovány všechny aktivní Relace, ty přejdou do stavu zrušena . Je notifikován Uchazeč, že byl odmítnut. Relace zpětně notifikuje o svém zrušení i Pozici, protože důvodem zrušení může být jindy ztráta zájmu ze strany Uchazeče.
Další příklad. Když relace přejde do stavu Uchazeč splnil všechny požadavky, tak musí být notifikována pozice, u níž dojde ke změně stavu jen tehdy, když se jedná o prvního přiřazeného uchazeče. Dále je notifikován uchazeč, který přejde do stavu Přijat.
Představme si nyní, že třídy Uchazeč, Pracovní pozice a Relace informaci o změně svého stavu nabídnou okolí ve formě událostí. Každý objekt z jedné třídy si přihlásí odběr událostí asociovaných objektů z dalších tříd a pak všichni spustí divokou událostní přestřelku se zběsilými kulkami v podobě vzájemných notifikací.
Když Pozice přejde do stavu zrušena, informuje první relaci, ta změní svůj stav na zrušena, relace svoji změnu stavu zašle uchazeči, ten přejde do stavu „Odmítnut“ a vyvolá svoji událost „Změna stavu“, tu odchytí Relace, která na stav „Odmítnut“ u uchazeče nereaguje. Relace informaci o svém zrušení zasílá vždy recipročně objektu Pozice. Pozice pod dokončení kolečka s první Relací notifikuje další Relaci a kolečko s mírně obměněnými aktéry proběhne znovu. Všechny objekty jsou při tomto vzájemném přeřvávání kandidáty na slušivou svěrací kazajku.
V čem je ale hlavní problém? Události nemusí být zpracovány ve správném pořadí. Představme si, že u Pozice z nějakého důvodu zavedeme další tranzitivní stavy „Vyžádáno zrušení pozice“, „Pozice je rušena“ a teprve finálním stavem je náš původní stav „Zrušena“. Do stavu „Vyžádáno zrušení pozice“ přejde pozice ihned po žádosti uživatelem (přesněji po volání metody Cancel), do stavu „Pozice je rušena“ , když je zpětně notifikována první Relací o jejím přechodu do stavu Zrušena. Pozice přejde do finálního stavu „Zrušena“ až po obdržení potvrzení o svém zrušení od všech dalších relací. Tady ale narazíme – když Pozice přejde do stavu „Pozice je rušena“, tak začne tuto událost rozesílat všem Relacím.
To znamená, že Relace2 a následující obdrží nejdříve informaci o přechodu Pozice do stavu „„Pozice je rušena“ a později o ( již nepravdivém) přechodu do stavu „Vyžádáno zrušení pozice“. Když se zkomplikují i stavové automaty dalších objektů, staneme se nechtěnými svědky rozhovoru bandy otrlých lhářů.:)
Pořadí při rozesílání událostí není sekvenční, a i když bychom mohli do objektu Pozice a dalších dopsat logiku, která se o sekvenční distribuci postará, nepůjde o šťastné řešení. Aby třída konvenovala svému okolí, dosadíme do ní znalost, jak si okolí komunikací představuje, a porušíme tak princip zapouzdření. Třída svému okolí sděluje, jaké změny v ní nastaly, ale nesmí se starat o reakce okolí. Třída musí být vždy nonkonformní a kašlat na své sousedy, jež ji nutí, aby se adaptovala na jejich způsob komunikace a chování. (BTW: Zjsitil jsem, že miluji OOP a návrhové vzory, protože k sousedům mám stejný postoj :) )
Odpovědnost za sekvenční rozesílání událostí přidělíme nové třídě Mediator. Po svém vytvoření budou objekty zaregistrovány v Mediatoru, který si přihlásí odběr jejich událostí. Třídám Pozice, Relace a Uchazeč přidáme metody, které budou volány mediátorem, když nastane událost. Například objekt Pozice bude mít metodu „NotifikujUchazečOdmítnut“, která bude mediátorem zavolána, když Relace přejde do stavu „Uchazeč odmítnut po psychotestech“ nebo do stavu „Zrušena“.
Aby mediátor nebyl příliš komplikovaný a nepřehledný, vytvoříme pro každou třídu jednoho zpracovatele události. Každý zpracovatel událost bude implementovat rozhraní s jedinou metodou „ZpracujUdálost“, které přijímá dva argumenty. Prvním argumentem je odkaz na objekt, který událost vyvolal, a druhým jsou parametry události. Zpracovatel „ví“, jaké metody musí u objektů volat pro každou jedinečnou kombinaci argumentů události. (Když zpracovatel objektu Relace obdrží událost „Přechod do stavu Zrušena“, tak zavolá u asociovaného objektu Pozice metodu NotifikujUchazečOdmítnut“ a u Uchazeče metodu „ZůstávášNezaměstnaným“:) )
Jak zajistíme sekvenční zpracování?
V událostních metodách mediátor odchytne událost a zavolá vždy jen obecnou metodu handleEvent, které kromě odesílatele a argumentů události přijímá odkaz na zpracovatele (m_JobHandler), jenž reaguje na danou událost. Objekt m_JobHandler zpracovává událost „StavZměněn“ třídy Pracovní pozice.
handleEvent(sender, e, m_JobHandler);
Metoda handleEvent
private void handleEvent(object sender, EventArgs e, BProcessEventHandlerBase processor)
{
EventStateHolder holder = new EventStateHolder(e, sender, processor);
m_eventsQueue.Enqueue(holder);
if (!m_inEventBubbling)
initEventBubbling();
}
Metoda handleEvent nejdříve uloží všechny informace o události do nové instance naší třídyEventStateHolder. Zde mimochodem vidíte kouzlo polymorfismu, protože naše třída EventStateHolder se nestará o detaily událostí, ale vyžaduje jen, aby argumenty události byly odvozeny z třídy EventArgs a zpracovatelé událostí z třídy (rozhraní) BProcessEventHandlerBase. Poté je událost zařazena do fronty (v .NET třída Queue) a jestliže se jedná o první událost, je zavolána metoda initEventBubbling, která se postará o předání události do zpracovatele. Tento kód je důležitý – bublání událostí je zahájeno jen při první události, všechny další události libovolných business objektů, které jsou přímou nebo nepřímou reakcí na první událost, jsou jen zařazeny do fronty a k novému spuštění distribuce událostí realizovaného metodou initEventBubbling nesmí dojít.
private void initEventBubbling()
{
Debug.Assert(m_eventsQueue.Count > 0, "BMediator events queue is empty!");
m_inEventBubbling = true;
while (m_eventsQueue.Count > 0)
{
EventStateHolder eh = (EventStateHolder) m_eventsQueue.Dequeue();
eh.Processor.ProcessEvent(eh.Sender, eh.EventArguments);
}
m_inEventBubbling = false;
}
V metodě initEventBubbling se nejdříve ujistíme, že fronta událostí není prázdná. Pak nastavíme privátní proměnnou m_inEventBubbling na true, aby metoda handleEvent již při zpracovávání návazných událostí metodu initEventBubbling nevolala. V jednoduchém cyklu while zpracujeme sekvenčně všechny události postupně přidávané do fronty po rozeslání každé události.
Mediatora můžete vylepšit. Ke každé události mohou být registrovány preprocesory, kteří například zalogují všechny události a postprocesory, odesílající manažerovi informaci o provedených změnách. Když budeme chtít rychle změnit chování aplikace bez zásahu do existujícího kódu, můžeme napsat nový preprocesor, který událost zpracuje zcela jinak, a protože z metody vrátí true (nepokračovat v distribuci událostí, již jsem vše udělal), tak se originální zpracovatel události nedostane ke slovu. Preprocesory načteme dynamicky při startu aplikace s využitím reflection API.
private void initEventBubbling()
{
Debug.Assert(m_eventsQueue.Count > 0, "BMediator events queue is empty!");
m_inEventBubbling = true;
while (m_eventsQueue.Count > 0)
{
EventStateHolder eh = (EventStateHolder) m_eventsQueue.Dequeue();
bool continueEventBubbling = distributeEventToPrePostProcessors(eh.Sender, eh.EventArguments, m_preProcessors);
if (continueEventBubbling)
{
eh.Processor.ProcessEvent(eh.Sender, eh.EventArguments); distributeEventToPrePostProcessors(eh.Sender, eh.EventArguments, m_postProcessors);
}
}
m_inEventBubbling = false;
}
private bool distributeEventToPrePostProcessors(object sender, EventArgs e, ProcessorCollection processors)
{
bool result = true;
foreach (IProcessor processor in processors)
{
if ((processor.ProcessEvent(sender, e)))
{
result = false;
break;
}
}
return result;
}
Také můžete přes mediátora řídit distribuci událostí transakčně s potvrzováním a vracením jednotlivých kroků a ukládat změny ve všech participujících objektech na konci úspěšné transakce do databáze.
Vzor Mediator je nepominutelnou dominantou každého návrhu aplikace, jež vyžaduje komplexní komunikaci mezi stavovými automaty různých tříd.
Sunday, June 06, 2004 8:53:00 PM (Central Europe Daylight Time, UTC+02:00)
Analytické drobky | UML | Návrhové vzory