V předešlé části článku bylo pojednáno o požadovaných znalostech analytika z oblasti technologií a základních pojmů z OOP:
- vztah třída-instance,
- generalizace
- polymorfismus
Kromě těchto nejzákladnějších znalostí by měl analytik znát navíc i některé ze vzorů Design Patterns. Důvodem je ta skutečnost, že některé z těchto vzorů mohou samy svou konstrukcí nabídnout řešení návrhu IS již na analytické úrovni. Při využití vzorů se řešení v analytické rovině navrhne pomocí vztahu Generalizace jak v CLASS MODELU, tak v USE CASE MODELU.
V této části článku bude uveden přehled těch vzorů, které by analytik (resp. každý vývojář) měl znát a o nichž by měl vědět nejen to, jak fungují, ale také jak a kdy se používají.
Vzor COMMAND
Jedná se o jeden ze základních a nejjednodušších vzorů GOF. O jeho nejčastějším použití napovídá již jeho alias (tj. sekundární název), který zní Action (Akce). Název vzoru Action je dost výstižný: Všude, kde se v požadavcích již na analytické úrovni objeví „handlování“ s akcemi, je výhodné využít řešení pomocí tohoto vzoru.
Poznámka: Z toho důvodu se mi druhotný název Action jeví jako výstižnější než originální název Command.
Vzor se nasazuje mimo jiné v těchto situacích:
- potřebujeme přiřadit akce k jiným prvkům v systému, zobrazit (dynamický) seznam akcí ke spuštění, budování dynamického menu apod.
- potřebujeme řešit spouštění povolených akcí v agendě přístupových práv
- potřebujeme okódování akcí, tj. přiřazení kódů (dat) k akcím, perzistence kódů akcí apod.
Typická věta ze scénáře USE CASE MODELU, která využívá znalost tohoto vzoru, zní takto:
{…
…obsluze se zobrazí seznam povolených akcí pro „nějaké X“ (prvek v systému), obsluha vybere akci a ta se spustí…
…}
Je velmi důležité, aby věty ve scénáři souhlasily s odpovídajícím návrhem v CLASS MODELU a USE CASE MODELU. V tomto případě se ve formulaci ve větě ve scénáři nejedná o „klasický switch“ (tj. např. ve tvaru „pokud má akce kód“ apod.), ale o využití polymorfismu zavedeného zde pomocí vzoru COMMAND. Je zřetelně vidět, že předešlý prostý zápis věty pomocí vzoru COMMAND ve tvaru „obsluze se zobrazí seznam povolených akcí…, obsluha vybere akci a ta se spustí…“ je jednodušší a paradoxně laicky srozumitelnější než klasické rozhodování přepínačem ve strukturovaném programování. Je vidět, že objektový zápis pomocí vzoru COMMAND odpovídá více „zdravému selskému rozumu“. Navíc je to zápis mnohem flexibilnější, protože nemusíme již měnit strukturu přepínače, stačí přidat další akci do seznamu akcí.
Vzor OBSERVER
Použití tohoto vzoru je popsáno v knize Analytické modelování pomocí UML v praxi, str. 144, kapitola Vzor Reakce. Jeho nepoužití už na analytické úrovni může vést k velmi nepříjemným důsledkům, zejména co se týče rozdělení aplikace na vrstvy. Zanedbání nebo dokonce neznalost tohoto vzoru vede k tzv. špagetovým efektům v systému, kdy nakonec dojde k provázanosti funkcionalit, volání z modulů do modulů a nakonec „vše souvisí se vším“ a systém nelze rozdělit na menší části.
Jako příklad si uveďme situaci, kdy při zaúčtování převodního příkazu v bance a tedy změně zůstatku na účtu se mají vyvolat další funkcionality v systému, které na tuto změnu čekají a mají se při této změně zůstatku spustit. Například při překročení limitu nízkého stavu na účtu mají nějak zareagovat úvěry anebo naopak při překročení nad nastavený limit mají reagovat termínované vklady, má se poslat SMSka apod. Pokud bychom v návrhu zavedli „přímé“ volání všech těchto funkcionalit v bodě, kde došlo ke změně zůstatku, máme zaděláno na problém hned ze dvou důvodů: Agenda převodních příkazů se díky tomu přímo prováže (tj. je ve vztahu Dependency) se všemi agendami, které volá a tím dojde k nežádoucím referencím mezi typy, které v referenci být neměly. Jinak řečeno, vnitřní původně nezávislá vrstva „ví“ o vrstvě vyšší a již není vnitřní vrstvou. Za druhé při každé nové další funkcionalitě, která také bude čekat na změnu zůstatku (například do určité doby nebyla služba poslání SMS zavedena a nyní má být zavedena) se musí původně nezávislá vrstva otevřít, změnit, překompilovat (a otestovat!).
Problém řeší vzor OBSERVER, který odstíní dané volání v tomto bodě tak, že vnitřní vrstva zůstane nezávislou a díky tomu do daného bodu lze přidávat flexibilně další volání funkcionalit, aniž by se měnil kód této vnitřní vrstvy.
Hlavním úkolem analytika je odhalit takovéto body OBSERVERA (zde změna zůstatku) již na analytické úrovni.
Poznámka: Existují také „body OBSERVERA“, které vznikají až díky technologii v technologickém návrhu, ty analytik samozřejmě nevyhledává.
Vzor STRATEGY
Podobně i zde je použití tohoto vzoru popsáno vcelku podrobně v knize Analytické modelování pomocí UML v praxi, str. 121, kapitola Vzor Výběr algoritmu. Vzor řeší situaci, která je v analýze dost běžná, kdy je na výběr několik způsobů zpracování resp. několik možných postupů ve scénáři a volí se jeden z nich. Je možné buď nasadit přepínač, anebo použít lepší, flexibilnější a dokonce ve scénáři čitelnější řešení pomocí tohoto vzoru, viz zmíněná kniha.
Další vzory GOF, které by vývojáři měli znát
Kromě těchto základních vzorů by se vývojáři měli seznámit minimálně ještě se vzory, které jsou uvedeny v následujícím výčtu:
- Vzor COMPOSITE – řeší situaci, kdy je v systému použita stromová struktura
- Vzor BRIDGE – odděluje část implementace od části logiky, důležité je znát jeho zobecnění, viz zmíněná kniha Analytické modelování pomocí UML v praxi, str. 85, kapitola Vzor Bridge alias Přemostění
- Vzor INTERPRETER – silný vzor, který napomáhá efektivně řešit návrh složitějších dopředu neznámých algoritmů zpracování skládáním kódu (re-usem), vznikne tak „skladačka kódu“. Uživatel si sám algoritmus poskládá včetně klasických příkazů strukturovaného programování včetně příkazů rozhodování, větvení a smyček (IF, WHILE atd.)
- Vzor TEMPLATE METHOD – účinný vzor v situaci, kdy je znám obecný scénář nějakého zpracování, ale jeho části (odstavce scénářů) se mohou případ od případu lišit způsobem zpracování
- Vzor VISITOR – řeší situaci, kdy jsou již struktury návrhu modelu tříd hotovy, naprogramovány a odevzdány, ale neví se dopředu, jaké informace je třeba z těchto struktur zpracovat a odevzdat. Struktury se proto připraví pro návštěvu VISITORA, který „vše zařídí“.
Závěr
Je velkým přínosem, pokud vývojář zná nejen základy použité technologie, ale také základy OOP a také vzory GOF a to minimálně v rozsahu, jak byly v tomto článku uvedeny. Znalost OOP a uvedených vzorů GOF pomohou nejen pochopit principy vztahu Generalizace (v UML jedna ze základních interakcí), ale také vlastnosti polymorfního chování. Pro správnou a kvalitní analýzu a vývoj jsou tyto znalosti nezbytné.
Konec článku
Napsat komentář