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í.