Wednesday, 26 September 2012
Tuesday, 30 August 2011
Sunday, 05 June 2011
O špatně chápaném principu jedné odpovědnosti třídy (SRP) a o zneužívání myšlenek Domain driven designu (DDD)
Dnes na twitteru David Grudl odkázal na debatu, která se týká vlastností v PHP. O vlastnostech v PHP mluvit nechci, ale v tomto příspěvku se chci dotknout některých “dogmat”, které se ozývají stále častěji a které byly použity jako univerzální kladivo na oponenty i v odkazované diskuzi.
Jedno zvláštní dogma se týká principu jedné odpovědnosti třídy (Single responsibility principle). Tento princip říká, že třída by měla mít jednu přesně vymezenou odpovědnost, která je v souladu s jejím názvem. I když na první přečtění se tento princip zdá neproblematický, dá se zneužít jako univerzální kladivo. Dogmatici mi říkali, že jedna odpovědnost si vynucuje, aby třída vždy měla právě jednu metodu, která tuto odpovědnost realizuje. Není nad přehledný svět objektových dogmatiků, kde objekt je jen stupidní kontajner na jednu (de facto globální?) funkci.
Dogmatiky tohoto zvláštního ražení zanedbejme jako ztracené případy a SRP obohaťme o další vysvětlení, které říká, že třída by měla mít jen jeden důvod ke změně. Tento princip je užitečný v tom, se snaží z aplikací odstranit všemocné božské (God) objekty, které mnohdy už svým názvem signalizují, že řeší spoustu věcí. UniversalOrderAndInvoiceProcessor oznamuje, že se bude měnit nejen, když se změní zpracování objednávek, ale také když se změní zpracování faktur. Jednoduché, což? Proč o tomhle jednoduchém principu vůbec dále mluvit?
V diskuzi se o SRP mluví (viz i příspěvky níže), ale diskutující tam ve své argumentaci používají něco, čemu na kurzech u SRP říkám falešné alternativy.
Mějme stejně jako v diskusi svou třídu Image, která nese informace o obrázku. Obrázek chceme uložit.
Varianta 1, kdy obrázek nese informace a současně nabízí metodu Save, ve které uloží data do souboru.
Co je v diskuzi vyčítáno této třídě? Porušuje princip jedné odpovědnosti, protože podle některých (Jiří Knesl, Ondřej Mirteš) řeší dvě věci najednou – nese data o obrázku a současně data ukládá. Souhlasím, že jde o porušení SRP, ale hlavním důvodem je to, že metoda Save je napsána tak, že třídu Image ukládáme vždy do souboru. Co když budeme chtít třídu Image uložit do nějakého “response” streamu na webovém serveru, nebo uložit přímo do databáze? Tuto třídu skutečně budeme měnit ze dvou důvodů – jednou, když přidáme nebo odebereme informace o obrázku a také, když budeme chtít ukládat obrázek do databáze, musíme rozšířit stávající metodu Save, což povede k tomu, že metoda bude mít v sobě nějaký podivný switch a bude trpět smíšenou odpovědností, protože bude dělat několik věcí najednou, nebo můžeme přidat novou samostatnou metodu SaveToDb.
Jedinou (!?) alternativou v diskuzi k tomuto postupu je vyvedení odpovědnosti za ukládání do různých úložišť do samostatných objektů, které mohou být skryty za jednotným rozhraním.
Toto řešení důsledně separuje odpovědnosti, navíc je velmi snadné přidat další implementaci rozhraní IImagePersistor, např. DbPersistor, který data uloží do databáze. Už v diskuzi Jakub Vrána ale upozorňuje na to, že se mu nelíbí, jak se řešení komplikuje pro uživatele-vývojáře, který s třídami bude pracovat, protože tento vývojář musí vědět, že existuje nějaký IImagePersistor/FilePersistor odpovědný za uložení dat. Třída Image nestačí k tomu, abyste dokázali vygenerovat data obrázku a uložit je, což může být ve vaší knihovně častý scénář. Také bych rád poprvé v tomto článku připomněl princip OOP, ke kterému se za chvíli vrátím, že objekt představuje jednotu svého stavu a chování, které je pro tento stav definováno.
Psal jsem o falešných alternativách, můžeme najít i jiná řešení. Co ponechat metodu Save ve třídě Image, ale z třídy Image udělat tzv kompozitor - objekt, který skládá své chování tak, že využívá další pomocné objekty, na kterých závisí, a nabízí intuitivní rozhraní pro klienty.
Odpovědnosti jsou stále separovány a dokonce třída Image, náš kompozitor, dodržuje pravidlo, které říká, že kompozitor by měl být jednodušší než suma funkcí jeho pomocných objektů. Klient třídy Image nemusí pracovat přímo s třídou FilePersistor, a přitom nemáme kód pro ukládání do souboru přímo ve třídě Image. Problém je, že metoda Save třídy Image vždy vytváří FilePersistor. Klient třídy Image si nemůže vyžádat to námi dříve zmiňované ukládání obrázku do databáze, a navíc třída Image závisí na jedné konkrétní třídě FilePersistor, u níž přímo volá konstruktor. V třídě Image mixujeme vytváření grafu spolupracujících objektů se samotným použitím pomocných objektů. Opět jde o dvě odpovědnosti, které bychom měli oddělit – SRP, nezapomeňme.
Nejprve ale zkusme vyřešit problém s tím, že klient nemůže ukládat data do databáze, protože třída Image ukládá data vždy do souboru.
Jednoduše přidáme další variantu metody, která přijímá odkaz na IImagePersistor, v našem případě třeba na DbPersistor. Původní metoda Save bez argumentů řeší ukládání do souboru. Ukládání do souboru je nejčastější scénář, který je zvolen jako výchozí. Stále ale tady máme problém s tím, že v metodě Save konstruujeme "natvrdo" FilePersistor. A navíc naše API klientům trochu lže. V podtextu klientovi sděluje, že výchozí metoda Save nemá žádné další závislosti, i když z implementace, !a jen z implementace!, je zřejmé, že jsme závislí na přítomnosti třídy FilePersistor. Poznámka: V C# 4 můžeme použít volitelné argumenty u jedné metody, ale na principu této varianty řešení se moc nemění.
Zkusme naše prozatím ulhané API vylepšit a dodržet SRP. Oddělme nyní konstrukci pomocných objektů, na kterých závisíme, od jejich použití v metodě Save.
Objekt Image si nyní v konstruktoru vynucuje předání IIMagePersitoru. Když klient IImagePersistor nepředá, objekt nezvznikne – sám konstruktor garantuje, že buď objekt Image má vyplněny všechny závislosti, nebo vůbec nevznikne. Vytvořili jsme konstruktor, který může použít a automaticky naplnit DI kontajner, nebo různé abstraktní továrny registrované v DI kontajneru apod. DI kontajner je přesně tím objektem, který by měl být v aplikaci odpovědný za konstrukci grafu objektů, v metodě Save objektu Image injektovaný IImagePersistor jen používáme. SRP v praxi.
Možný že ale v tomto případě je injektování závislostí přes konstruktor moc striktní. Co když nám skutečně vyhovuje, že můžeme bez DI kontajneru vytvořit objekt Image, který bude data ukládat do souboru. Pak můžeme využít injektování přes vlastnosti, kdy příslušnou vlastnost po vzniku objektu vyplníme rozumnou výchozí hodnotou – v našem případě instancí FilePersistoru. Poté ale platí, že třídu Image stále částečně zatěžujete konstrukcí objektů…
U většiny DI kontajnerů je preferováno injektování závislostí přes konstruktory, všechny, které znám, si ale poradí ale i s injektováním závislostí přes vlastností a u MEFu bych řekl, že injektování závislostí pomocí vlastností hrají prim.
Všechny tyto varianty mají své výhody a nevýhody a asi nemusím zdůrazňovat, že ani jedna není univerzálním kladivem. Varianty s injektováním závislostí (konstruktor, metoda, vlastnost) jsou samozřejmě mnohem lépe testovatelné.
Dokážu přidat i další příklady, ale chtěl jsem, abyste viděli, že SRP není ani nesmysl, ale ani princip, který by, podobně jako to zaznělo v diskuzi, sděloval – existují jen dvě alternativy, jak rozdělovat odpovědnosti, a ZROVNA TA TVOJE JE ŠPATNĚ.
A poslední poznámka:
Jiřé Knesl také v diskuzi uvedl: “ objekt buďto data reprezentuje (pak má settery/gettery), nebo vykonává činnost (pak dostane data parametry)”. Tohle je podle mě postoj blízký hlavně některým Javistům, o čemž svědčí i podle mého soudu schematický a nevěrohodný článek, který se zabývá vlastnostmi v Javě a na který se J. Knesl odkazuje. Znovu připomínám, že objekt představuje jednotu svého stavu a chování, které je pro tento stav definováno. Objekt, který má jen gettery a settery, je ”krabičkou na data”, pouhou strukturou známou i z neobjektových jazyků, a když má objekt jen metody, tak jde o (v mnoha případech skutečně globální) funkce/procedury, které prefixujeme názvem proměnné/třídy. V diskuzi to myslím nezaznělo, ale když někdo razí tuto drastickou separaci chování od samotných dat, často dodává, že takto je to přece definováno Evansem, tedy autoritou, v kanonické knize o Domain Driven Designu. Když se ptám, kde o tom Evans mluví, dozvím se, že Evans má objekty, které mají svůj stav (vlastnosti) a s objekty pracují speciální business-doménové služby (chování). I když mám vůči DDD spoustu výhrad, zde Evanse špatně interpretují – Evans by model, kde objekty mají jen stav a nemají žádné chování, nazval anemickým modelem – izolovaná data podepřená berličkami nesouvisejících globálních funkcí. Business služby jsou, zjednodušeně řečeno, určeny pro zapsání složitější business logiky, na které spolupracuje více objektů a žádný participující objekt není sám o sobě přirozeným kandidátem, do kterého by bylo vhodné logiku situovat.
Zde bych mohl pokračovat dále k rozdělení objektů v DDD, ke skutečnému významu vlastností u objektu, co říká princip “tell, don't ask”, ale už teď mi původně krátký komentář k SRP a DDD až moc nabobtnal. Když budete mít zájem o další naznačená témata, napište prosím komentář k článku.
Sunday, 05 June 2011 21:13:04 (Central Europe Standard Time, UTC+01:00)
Analytické drobky | C# | Návrhové vzory | UML
Monday, 30 May 2011
Pár triviálních poznámek k vývoji aplikací
Dostal jsme dotaz, jak si poradit s odstraňováním chyb u starší a rozsáhlé aplikace. Když jsem odepisoval, uvědomil jsem si, že sepisuju jakési “triviální desatero vývoje”", které se snažím už dlouhou dobu svému okolí vtloukat dohlavy. I když jde o triviální zásady, budu příště odkazovat raději na tento příspěvek, než abych vše opakoval pokaždé znovu. Jméno firmy je v textu nahrazenou souslovím “anonymní firma”.
“Zdravím,
to je na hodně dlouhý příspěvek.
Alespoň tedy:
1) Je nutné zrušit umělou hranici mezi vývojáři a testery. Žádná výměna informací přes šéfy oddělení nebo pověřené osoby.
2) Na každou objevenou chybu musí být napsán automatický test, který zajistí, že chyba neprobublá do dalších releasů. Bez toho žádné organizační opatření nefunguje. Bez napsaného testu se chyba nepovažuje za odstraněnou, ale jen za náhodou se nyní neprojevující.
3) Vytvořit malé sebeorganizující týmy odpovědné za určitou část projektu (nastálo, nebo do dalšího releasu). V čele team leader, který garantuje kvalitu. Team leader je k dispozici i testerům a řeší nesrovnalosti v analýze a systémovém designu. S dalšími team leadery řeší problémy integrace různých částí projektu. Team leader ale stále většinu času kóduje, není to embryo vychovávané pro střední management.
4) Je potřeba postupně napsat velké množství automatických testů (unit, integrační, akceptační) tak, aby se testeři věnovali hlavně novým záležitostem v releasu a aby vývojáři ani testeři nebyli obětí "ručně prováděných" regresních testů, které mají formu nikdy nekončícího debugování. Tím se i zkrátí doba, kterou "anonymní firma" nutně musí trávit opakovaným debugováním a "ručním" nalézáním příčin chyb. Automatizované testy představují práci, která se na projektech vyplatí, a navíc jde i o mnohem levnější řešení problému, než nabírání dalších a dalších testerů.
5) Nedávat žádné fixní odhady na odstranění chyb ani nikoho exkluzivně nealokovat jen na odstraňování chyb. Vývojář není a přes různé manažerské poučky ani nebude anonymní zdroj, který sebereme z jiného projektu, posadíme k aplikaci, kterou nezná, ale u které dostane befelem, že za jednu normohodinu musí odstranit 20 bugů. Tato kouzla fungují jenom v Excelu. V reálném světě vývojář těch 20 bugů neodstraní, ani když ho posadíte do open space, který je oblepen motivačním majstrštykem vytisknutým z PowerPointu nejlepším absolventem MBA.
Pokud se objeví chyba, chopí se jí člověk, který za danou oblast odpovídá (konflikty přinejhorším vyřeší team leadeři). Vývojář neustále čte a refaktorizuje kód, pokud možno ihned také odstraňuje chyby . A jsme opět u testů - dokud ty automatizované testy mít nebudete, vývojáři do kódu raději nezasahují, protože nevědí, kde všude se změna projeví a raději neriskují další možnou příčinu pádu aplikace po nasazení u zákazníka. A psát použitelné, ne jen formální-švejkovské testy, kdy se hodnotí "jen code coverage", se musí všichni vývojáři naučit a nějakou dobu to zabere.
Mám zkušenost s 12 let starou aplikací psanou původně pro VB, poté čátečně přepsanou na .Net Framework, která byla po 9 letech postupně obalena testy, a ani dnes sice nejde o žádnou vývojářskou lahůdku, ale pracuje se na ní beze strachu, co při každé změně v aplikaci zničíme. Nic jiného než to, co píšu výše, se mi neosvědčilo.
A pak další záležitosti jako (nutné) bonbonky:
- Neztrácet čas “mergováním” změn v něčem tak zastaralém a nepohodlném jako je Subversion. V Mercurialu (GITu) je propagace změn z vývojové větve do hlavní (a zpět) otázka chvíle. V Subversion ani TFS jsem po pár zkušenostech raději moc "branchů" nedělal.
- Automatické buildy spojené s již napsanými testy.
- Automatické nasazení nové verze aplikace, aby testeři nemuseli pátrat, kde seženou novou verzi a také, aby nasazení do produkčního prostředí neznamenalo 3denní práci party lidí, kteří se metodou pokus-omyl snaží dostat aplikaci do použitelného stavu u zákazníka.
- Alespoň u nováčků code review, abyste rychle odstranili jejich špatné návyky.
- Statická analýza kódu.
A dovolím si jednu soukromou poznámku k "anonymní firmě" - pokud možno zredukovat/vyhodit všechny těžkotonážní, neskutečně drahé a pro vývojáře zabijácké nápady se zavedením nejhorší možné formy vodopádu - analýza->samostatný systémový design->vývoj->testy, v jehož bludném pádu se bude produkovat množství dokumentů, navíc rychlokvašenými analytiky/designery, v mizerné kvalitě a bez vazby na skutečné potřeby projektu. Analýza a systémový design jsou fáze projektu, které pomáhají jen do doby, než se jich chytí nějaký exot, který nikdy žádnou aplikaci nevyvíjel a který si myslí, že analytická práce spočívá ve štosování nahodilých myšlenek zákazníka do příslušné šablony pro use case. Což je dle mých zkušeností většina “čistých”, míněno vývojem nedotčených, analytiků na pracovním trhu.
Monday, 30 May 2011 09:31:24 (Central Europe Standard Time, UTC+01:00)
Analytické drobky | Návrhové vzory | Ostatní | UML
Monday, 16 May 2011
Pozvánka na kurzy objektových principů a návrhových vzorů – podzim 2011
Opět vás všechny zvu na pravidelný podzimní běh kurzů Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací 1 a Pokročilé návrhové vzory a objektové principy 2.
Novinkou v tomto roce je kurz pro začátečníky nazvaný Základy objektově orientovaného návrhu a vývoje. Někteří z vás ho mohli během posledních dvou let absolvovat ve formě inhouse kurzu pod interním názvem UML 0. Kurz UML 0 vznikl velmi spontánně jako reakce na požadavky některých firem, které nechtěly rovnou absolvovat stávající kurzy. Nyní je vycizelované UML 0 dostupné i jako veřejný kurz, protože v emailech se opakovaly žádosti o jeho veřejnou formu od lidí, kteří kurz absolvovali a nyní na něj chtěli poslat své kolegy.
O tomto novém kurzu naleznete podrobné informace níže v této pozvánce. Znovu opakuji, že se jedná o kurz pro začátečníky, který dříve v nabídce nebyl, protože kurzy Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací 1 a Pokročilé návrhové vzory a objektové principy 2 byly a stále jsou určeny pro lidi, kteří základy znají. Nenechte se ale zmást “kódovým” názvem nového kurzu (UML 0), účastníci bývají překvapeni, že s UML na kurzu zacházíme zcela pragmaticky a bez posvátné úcty, ale i bez módních předsudků a rychlých odsudků. UML bereme jako nástroj, a ne jako samoúčelný cíl našeho snažení na kurzu.
Veřejný kurz Základy objektově orientovaného návrhu a vývoje (UML 0)
Datum konání kurzu: 19. 9. – 21. 9. 2011
Místo konání:
Školící středisko Tutor
U Půjčovny 2
110 00 Praha 1
Po celý den máme k dispozici wifi připojení a samozřejmě také teplé a studené nápoje. V ceně kurzu jsou obědy v hotelu.
Podrobné informace o kurzu a možnost přihlásit se na kurz
Program kurzu
FAQ - často kladené dotazy ke kurzům
Veřejný kurz Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací 1
Datum konání kurzu: 10. 10. – 12. 10. 2011
Místo konání:
Školící středisko Tutor
U Půjčovny 2
110 00 Praha 1
Po celý den máme k dispozici wifi připojení a samozřejmě také teplé a studené nápoje. V ceně kurzu jsou obědy v hotelu.
Podrobné informace o kurzu a možnost přihlásit se na kurz
Program kurzu
Výběr z ohlasů na kurz
FAQ - často kladené dotazy ke kurzům
Veřejný kurz Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací 2
Datum konání kurzu: 24. 10. – 26. 10. 2011
Místo konání:
Školící středisko Tutor
U Půjčovny 2
110 00 Praha 1
Po celý den máme k dispozici wifi připojení a samozřejmě také teplé a studené nápoje. V ceně kurzu jsou obědy v hotelu.
Podrobné informace o kurzu a možnost přihlásit se na kurz
Program kurzu
Výběr z ohlasů na kurzy
FAQ - často kladené dotazy ke kurzům
Program nového kurzu Základy objektově orientovaného návrhu a vývoje (UML 0)
Předpokládané znalosti účastníků
- Základní přehled o etapách vývoje projektu.
- Vhodné je mít nějaké vlastní zkušenosti z analýzy a vývoje projektů, abychom mohli porovnat různé postupy a doporučení a jejich použitelnost v praxi.
- Chuť se učit.;) Schopnost pohlédnout na některá domněle známá témata bez předsudků.
- Částečná znalost UML je vhodná, ale u tohoto kurzu není vyžadována. Vhodná je hlavně pro konfrontaci vlastních zkušeností s tím, co zazní o použitelnosti různých částí UML na kurzu.
- Nenávist ke kariéře zručného "bušiče", nikým nerespektovaného projektového vedoucího (tzv. sekretářky 2.0) a neschopného analytika / vývojáře.
Obecné informace ke kurzu
Pro vývojáře se u konstrukcí a prvků jazyka UML, které jsou považovány za analytické, dělají časté odbočky do kódu, aby vývojáři pochopili, že UML ani principy OOP nejsou nějaké nesmyslné abstrakce, ale užitečné konstrukce, které sami v programovacích jazycích používají denně. U role analytika stále zdůrazňuji, jaké znalosti z oblasti vývoje aplikací musí analytik mít, aby byl pro projekt užitečný a nevytvářel jen dokumentaci pro dokumentaci, kterou vývojáři nevyužijí a (až příliš často oprávněně) ji považují za nesmyslnou, drahou a hlavně vyvíjenému projektu nic nepřinášející. Kurz je určen pro vývojáře, systémové designery, analytiky a projektové manažery, kteří se chtějí seznámit se základními principy objektového programování a s modelováním v jazyce UML.
Program školení
- Proč má dnes UML v některých kruzích špatnou pověst? Musíte být těžkotonážní rytíři cválající na drahých CASE nástrojích a neživotných formálních projektových metodikách, nebo si vystačíte s nástroji a postupy, které zachytí vaše myšlenky, ale nenutí vás přizpůsobovat se "Jen Tomu Jedinému Pravému Stylu Návrhu A Vývoje"?
- Dostali jste poptávku, máte za pár dní dodat nabídku a v seznamu svých dovedností nenalézáte jasnovidectví ani nemáte po ruce čarovnou skleněnou kouli, abyste zákazníkovi do nabídky vyvěštili konečnou cenu i datum dokončení projektu? Co dělat v počáteční fázi projektu, kdy ještě ani nevíte, jestli budete projekt vyvíjet?
- Požadavky na systém. Jak je to s případy užití? Má vlastní zrychlená funkční specifikace bez zbytečných formalit.
- Rozsáhlé ukázky fukčních specifikací z projektů.
- Diagram tříd v UML.
- Rozdíl mezi analytickým diagramem tříd a diagramem tříd vytvářeným ve fázi systémového designu - existuje takový rozdíl, nebo jde jen o další hloupý mýtus?
- Třída - základní principy OOP, operace, atributy, viditelnost členů třídy.
- Vztahy mezi elementy diagramu (asociace, agregace, generalizace, závislost, realizace) – vše vykládáno na konkrétních příkladech z praxe + ukázky nejčastějších chyb, se kterými jsem se setkal.
- Dobře zapamatovatelné principy návrhu známé pod zkratkou SOLID v příkladech. Unit testy, integrační testy, akceptační testy - skutečně si stále myslíte, že se bez nich na projektech obejdete?
- Nejen SOLIDní principy stojí v pozadí návrhu aplikací...
- Nenásilný přechod k jednoduchým návrhovým vzorům.
- Příklady složitých diagramů tříd. Jak je udržovat v souladu s napsaným kódem? A musíme je udržovat? Co se na projektech vyplatí dělat a co projekt spolehlivě zabije?
- Objektový diagram + příklady.
- Diagramy a diagramy interakce. Příklady. Typy projektů, pro které se tyto diagramy hodí.
- Vysvětlení stavových diagramů + výhody aplikací řízených přesně definovanými stavovými automaty.
- Diagram aktivit - modelování složitých business procesů v organizaci. Hrajete si s diagramem aktivit rádi, ale ocení to Váš zákazník?
- Vrstvy a moduly v aplikaci – architektura aplikace.
- Relační a objektový svět? Stále jediné možné partnerství z rozumu?
- Nasazení aplikace – výklad Component & Deployment diagramů.
- OOP a jeho vztah UML. Vztah UML a OOP k projektové praxi a realitě.
- Výhody a nevýhody UML – vyzdvižení nejvíce používaných postupů, odhození nepotřebné veteše z jazyka UML.
- Odpovědi na dotazy frekventantů kurzu.
Těším se s Vámi na setkání na kurzu!
René Stein
Monday, 16 May 2011 11:15:38 (Central Europe Standard Time, UTC+01:00)
Analytické drobky | Kurzy UML a OOP | Návrhové vzory | UML
Saturday, 18 September 2010
Pozvánka na mé kurzy OOP, UML a návrhových vzorů a odpovědi na některé dotazy zaslané emailem - podzim 2010
Opět bych Vás všechny rád pozval na pravidelný podzimní běh kurzů Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací 1 a Pokročilé návrhové vzory a objektové principy 2. Níže také naleznete odpovědi na pravidelně se opakující dotazy v emailech.
Veřejný kurz Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací 1
Datum konání kurzu: 22. 11. – 24. 11. 2010
Místo konání:
Školící středisko Tutor
U Půjčovny 2
110 00 Praha 1
Po celý den máme k dispozici wifi připojení a samozřejmě také teplé a studené nápoje. V ceně kurzu jsou obědy v hotelu.
Podrobné informace o kurzu a možnost přihlásit se na kurz
Program kurzu
Výběr z ohlasů na kurz
Veřejný kurz Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací 2
Datum konání kurzu: 29. 11. – 1. 12. 2010
Místo konání:
Školící středisko Tutor
U Půjčovny 2
110 00 Praha 1
Po celý den máme k dispozici wifi připojení a samozřejmě také teplé a studené nápoje. V ceně kurzu jsou obědy v hotelu.
Podrobné informace o kurzu a možnost přihlásit se na kurz
Program kurzu
Výběr z ohlasů na kurzy
Zde jsou některé nové ohlasy na kurzy. Raději podotýkám, že tato hodnocení jsou mi zaslána účastníky z vlastní vůle a já určitě účastníky nenutím, aby mi psali nějaká hodnocení, natož lichotivá, hned na kurzu ani po něm, jak se prý děje u konkurence.
pan Martin Pospíšil, společnost Team Trackers s. r. o.
Děkuji za materiály a za výborné školení. Líbilo se mi ještě víc než jednička, díky těm praktickým příkladům, které jsme řešili společně.
Ing. Rudolf Plíva, společnost NOWIRE
Děkuji za velmi zajímavé a přínosné školení!
pan Jiří Filous, společnost Česká pojišťovna a. s.
Ano, mám zájem o zasílání informací o nových kurzech a děkuji za skvělé (i když náročné) školení.
Odpovědi na některé dotazy, které jsme obdrželi od dříve přihlášených zákazníků emailem.
Otázka: Na kurz půjdu, ale raději počkám s přihláškou na týden před školením, protože stejně jako konkurence mi dáte “last minute” slevu ne?
Odpověď: Hry s nějakou uměle nadsazenou cenou, která je potom těsně před kurzem snižována a nabízena v rámci “Last minute” nabídky, nehrajeme. Přijde mi nespravedlivé a nesmyslné, aby každý účastník platil jinou částku v závislosti na dni přihlášení. Všichni dosavadní účastníci mohou potvrdit, že zaplatili cenu, která je uvedena u školení a je jedno, zda se přihlásili 3 měsíce nebo 3 dny před kurzem.
Otázka: Na kurzu bychom rádi diskutovali záležitosti, které se týkají našeho projektu, je to možné? Je možné s vámi probrat podrobně i vývojářské specialitky, které se týkají C#, C++,Windows Forms, Silverlightu, Windows Mobile….
Odpověď: Na veřejném kurzu můžeme diskutovat o věcech, které zajímají všechny účastníky. Specifické dotazy, které se týkají vašich projektů, je nejlepší probrat se mnou po 16. hodině, kdy skončí oficiální část kurzu, ale já jsem vám samozřejmě k dispozici od 16:00 do umdlení mého či vašeho. Jestliže chcete 3 dny věnovat jen svému projektu, zvažte inhouse variantu kurzu, kde si můžete témata definovat sami. Pro podrobné informace o podmínkách inhouse kurzů napište prosím Petře Steinové (petra@renestein.net), která Vám velmi ráda obratem pošle nabídku.
Těším se s Vámi na setkání na kurzu!
René Stein
Saturday, 18 September 2010 10:17:31 (Central Europe Standard Time, UTC+01:00)
Analytické drobky | Kurzy UML a OOP | Návrhové vzory | UML
Wednesday, 07 April 2010
Pozvánka na kurz Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací 1 – jaro 2010
Update: Kurz je zcela obsazen včetně náhradníků.
Rád bych Vás pozval na další běh kurzu Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací 1. Pokud se někdo z Vás (oprávněně) diví, proč tak pozdě a proč Vás nezvu i na kurz OOP 2, níže v tomto spotu nalezne odpovědi.
Veřejný kurz Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací 1
Datum konání kurzu: 14. 6. – 16. 6. 2010
Místo konání:
Školící středisko Tutor
U Půjčovny 2
110 00 Praha 1
Po celý den máme k dispozici wifi připojení a samozřejmě také teplé a studené nápoje. V ceně kurzu jsou obědy v hotelu.
Podrobné informace o kurzu a možnost přihlásit se na kurz
Program kurzu
Výběr z ohlasů na kurz
Odpovědi na některé dotazy, které jsme obdrželi od dříve přihlášených zákazníků emailem.
Otázka: Proč se kurz nekoná na předchozím místě (v hotelu Villa), kde byli naši kolegové?
Odpověď: Po vyhodnocení ohlasů na kurz jsme zjistili, že účastníci nebyli (stejně jako já ) příliš spokojeni s jídlem. Také jsme při domlouvání hotelu byli ujišťováni, kolik účastníků se může na kurz přihlásit a jak lze pro ně uspořádat pohodlně prostory, a tyto informace se v průběhu kurzu jevily jako marketingové fráze až blafy velmi optimistickými nebo nepočítaly s průměrným Evropanem, ale standardním liliputem. Stručně řečeno – poměr cena/výkon nebyl u čtyřhvězdičkového hotelu příliš dobrý. Jedinou výhodou hotelu Villa bylo parkování, nyní bude lepší na ”poslední míli” použít MHD.
Otázka: Proč se koná kurz tak pozdě (oproti přechozím rokům) a proč se nekoná kurz OOP2.
Odpověď: Byl a jsem vytížen tento rok dalšími projekty a nalézt vhodné termíny bylo problematické. Také jsme sháněli nové prostory, kde se bude kurz konat (viz předchozí odpověď). Termín kurzu OOP2 vycházel již na červenec a v době dovolených nemá smysl kurz pořádat. Při větším zájmu vyhlásím (co nejdříve) více termínů kurzu OOP2 na podzim.
Těším se na setkání na kurzu!
Wednesday, 07 April 2010 12:48:36 (Central Europe Standard Time, UTC+01:00)
Analytické drobky | Kurzy UML a OOP | Návrhové vzory | UML
Sunday, 21 March 2010
Výhody a nevýhody softwarových továren
Emailem jsem dostal zajímavou otázku, jaký je můj názor na softwarové továrny a kde vidím výhody a nevýhody softwarových továren. Odpověď nakonec publikuji i zde – už jen proto, že jsem si při jejím psaní uvědomil, že na továrnu kladu stejné nároky jako na kteroukoli další knihovnu v systému a že výběr softwarové továrny se u mě moc neliší od výběru třeba ORM Frameworku. Nejde o taxativní výčet výhod a nevýhod, ale spíš o volně nahozená témata, která mě za 20 minut psaní příspěvku napadla.
SW továrny jsou jen pokračováním trendu, že nemá smysl vynalézat znovu kolo ani v případě, že by bylo o dvě setiny procenta krásnější než to staré, které je již navržené a hotové. SW továrna říká – namísto opakování chyb svých předchůdců použijte ověřené zkušenosti, osvědčené praktiky, doporučené postupy a již otestovaný kód. Namísto obecného návrhového vzoru nebo vágně popsaného doporučovaného postupu máte k dispozici osvědčenou knihovnu, základní průvodce a odborný polštář, který by měl zabránit, že napácháte v dané oblasti velké množství hrubých bezpečnostních nebo jen s duchem technologie neslučitelných chyb.
Takže výhody:
1) Osvědčená řešení ihned po ruce. Tím se cíl SW faktory moc neliší od obecných frameworků a návrhových vzorů.
2) Není nutné psát infrastrukturní kód přímo v SW firmě (ISV). Je možné se soustředit na problémovou doménu zákazníka a ne na to, jak centrálně publikovat události nebo jak propojit různé pohledy v aplikaci tak, aby spolu dokázaly komunikovat .
3) Pokud stejnou továrnu používáte napříč všemi projekty, je zaučení nového vývojáře na dalším projektu jednodušší a rychlejší.
4) SW továrna používá praktiky osvědčené v dané technologii. Takže odlišně jsou zakódovány původně platformně nezávislá doporučení a všeobecně zaměřené vzory v SW továrně pro ASP.Net a jinak pro Silverlight. Místo popisu obecných návrhových vzorů je již vzor adaptován na konkrétní cílové prostředí.
Nevýhody:
1) Kód nemáte pod kontrolou a musíte se spolehnout, že továrna sama neobsahuje příliš kritických chyb ani otravných chyb s nižší prioritou. To platí o jakékoli abstrakci (frameworku, knihovně), kterou na projektu používáte, ale myslím, že ani v Microsoftu stále nemají SW továrny stejnou podporu jako samotný .Net Framework. A také by měla být známa alespoň orientační roadmapa SW továrny, abyste věděli, kam autoři směřují a jestli jsou si vědomi nevýhod a omezení stávající verze SW továrny. Od továrny, která se ihned po svém uvedení honosí přídomky „experimentální, testovací, zkušební“, bych dal ruce pryč. Jen ti nejodvážnější z nás si dovolí svým zákazníkům za půl roku po zatracení SW továrny jako slepé uličky tvrdit, že musí trochu poštelovat kardiostimulátor výkonného srdce aplikace a že místo plánovaných dvou hodin za přidání dvou vlastností do objednávky zákazník zaplatí dva měsíce migrace na jinou SW továrnu. Nenechal bych se zmýlit tím, že některé firmy pro odvážlivce používající jejich experimentální SW továrny a frameworky razí lichotivý titul „early adopter“ – méně korektní a pravdě bližší překlad z marketingového slovníku totiž zní „natěšený všehoschopný blbec“.
2) Univerzální řešení jako je SW továrna může být pro jednoduché aplikace zabijákem. Více času strávíte integrací aplikace do rámce vynucovaného SW továrnou než psaním obchodní logiky specifické pro aplikaci a důležité pro zákazníka.
3) U některých složitějších aplikací zjistíte, že rámec SW továrny je příliš těsný a vy potřebujete SW továrnu pro svůj projekt upravit nebo rozšířit. Náklady na rozšíření služeb , „hackování“ a ohýbaní SW továrny pro danou problematiku mohou převážit nad výhodami SW továrny. Z velké radosti nad úsporou času v raných fázích projektu, kde byla továrna použita, můžete ještě před dodáním první verze projektu a po pořádném časovém skluzu, vynuceném třeba přepisem částí továrny, které pro výkonnostních testech nestačí stávajícím požadavkům na projekt, přejít k jadrným kletbám nad šílenou SW továrnou, v níž si úprava jednoho modulu kaskádově vynutí úpravy všech dalších modulů. Místo používání původně slibované elegantní černé skříňky s jednoduchými službami se prohrabujete nevábnými vyhřezlými vnitřnostmi mizerně navržené SW továrny.
Z výhod a nevýhod snad vyplývá můj postoj k SW továrnám. SW továrny jsou dalším evolučním stádiem na cestě, jejímž cílem je využít pro danou problematiku osvědčená řešení a postupy, nepsat stále se opakující kód nebo v každém řešení už jen změnou typu klienta (Web, Windows Forms, Silverlight, mobilní aplikace) neprocházet znovu a znovu všechny slepé vývojářské uličky specifické pro použitou technologii. Objevování objeveného ponechme těm, kterým stačí zařvat vítězoslavně heuréka, i když jsou v pořadí stí nebo tisící, kteří stejnou infrastrukturní nebo funkční trivialitu konečně zakódovali rozumným a v životním cyklu projektu dále udržovatelným způsobem.
A samozřejmě si nemyslím, že tohle evoluční stádium je konečné. :)
Sunday, 21 March 2010 11:57:10 (Central Europe Standard Time, UTC+01:00)
.NET Framework | Analytické drobky | Návrhové vzory | UML
Sunday, 20 September 2009
Pozvánka na podzimní kurzy (OOP, UML, základní a pokročilé návrhové vzory)
Aktualizace 10. 11. 2009- I veřejný kurz Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací 2 je zcela obsazen včetně náhradníků. Další kurzy se budou konat na jaře 2009. Jestliže máte předběžný zájem a chcete si rezervovat místo, pište prosím na adresu petra@renestein.net.
Aktualizace 15.10.2009 - veřejný kurz Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací 1 je zcela obsazen včetně náhradníků. Je možné se již hlásit pouze na kurz Pokročilé návrhové vzory a objektové principy 2.
Rád bych Vás pozval na podzimní kurzy OOP a UML a představil oficiálně InHouse kurz, který postupně vykrystalizoval z požadavků zákazníků (OOP 0 - Objektové programování a UML prakticky - rychlý úvod do světa (nejen) objektového programování).
Osnova InHouse kurzu OOP 0 – Objektové programování a UML prakticky – rychlý úvod do světa (nejen) objektového programování:
Školení má dvě varianty - pro vývojáře i u konstrukcí a prvků jazyka UML, které jsou považovány za analytické, se dělají časté odbočky do kódu, aby vývojáři pochopili, že UML ani principy OOP nejsou nějaké nesmyslné abstrakce, ale užitečné konstrukce, které sami v programovacích jazycích používají denně.
U varianty pro „čisté“ analytiky jsou digrese do kódu minimalizovány, i když v některých místech stále zdůrazňuji, jaké znalosti z oblasti vývoje aplikací musí analytik mít, aby byl pro projekt užitečný a nevytvářel jen dokumentaci pro dokumentaci, kterou vývojáři nevyužijí a (mnohdy oprávněně) považují za nesmyslnou, drahou a projektu nic nepřinášející.
V kurzu se naučíte modelovat jednoduché i složité aplikace s využitím jazyka UML tak, aby následné kódování nebylo výletem do neznáma s nejistými výsledky, ale dobře čitelnou cestou bez temných a záludných míst vedoucích k selhání projektu.
Kurz je vhodný zvláště pro ty, kteří již nejsou spokojeni s vývojem projektů naivním "hurá" způsobem, kdy bez ohledu na složitost systému nevzniká žádný návrh a ihned se přistupuje ke kódování se všemi špatnými důsledky jako jsou podcenění technické a časové náročnosti implementace nebo vytváření drahých a nespravovatelných systémů.
Kurz je určen pro vývojáře, systémové designery, analytiky a projektové manažery, kteří se chtějí se seznámit se základními principy objektového programování a s modelováním v jazyce UML.
· Požadavky na systém a modelování pomocí případů užití (+ příklady).
· Zrychlená funkční specifikace bez zbytečných formalit – příklady.
· Diagram tříd v UML - vztahy mezi elementy diagramu (asociace. agregace, generalizace, závislost, realizace) – vše vykládáno na konkrétních příkladech z praxe + ukázky nejčastějších chyb, se kterými jsem se setkal. Třída, základní principy OOP, operace, atributy, viditelnost členů třídy. Nenásilný přechod k jednoduchým návrhovým vzorům.
· Příklady složitých diagramů tříd.
· Objektový diagram + příklady.
· Sekvenční diagramy a diagramy interakce.
· Vysvětlení stavových diagramů + výhody aplikací řízených přesně definovanými stavovými automaty.
· Diagram aktivit - modelování složitých business procesů v organizaci.
· Výhody a nevýhody UML - vyzdvižení nejvíce používaných postupů, odhození nepotřebné veteše z jazyka UML.
Pokud máte o kurz zájem nebo potřebujete další informace, napište prosím na adresu petra@renestein.net.
Veřejný kurz Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací 1
Datum konání kurzu: 2. 11. – 4. 11. 2009
Místo konání: Hotel VILLA Praha Okrajní 1, 100 00, Praha 10
U hotelu VILLA je možné parkovat, po celý den máme k dispozici wifi připojení.
Na kurzu jsou samozřejmě po celý den teplé a studené nápoje a v ceně kurzu jsou obědy v hotelu.
Podrobné informace o kurzu a možnost přihlásit se na kurz
Program kurzu
Výběr z ohlasů na kurz
Veřejný kurz Pokročilé návrhové vzory a objektové principy 2
Datum konání kurzu: 23. 11. – 25. 11. 2009
Místo konání: Hotel VILLA Praha Okrajní 1, 100 00, Praha 10
U hotelu VILLA je možné parkovat, po celý den máme k dispozici wifi připojení.
Na kurzu jsou samozřejmě po celý den teplé a studené nápoje a v ceně kurzu jsou obědy v hotelu.
Podrobné informace o kurzu a možnost přihlásit se na kurz
Program kurzu
Výběr z ohlasů na kurzy
Sunday, 20 September 2009 17:25:11 (Central Europe Standard Time, UTC+01:00)
Analytické drobky | Kurzy UML a OOP | Návrhové vzory
Tuesday, 11 November 2008
Pozvánka na kurzy - nový kurz Pokročilé návrhové vzory a objektové principy 2
Rád bych Vás pozval na další běh kurzu Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací 1 a hlavně Vás chci seznámit se zcela novým kurzem Pokročilé návrhové vzory a objektové principy 2.
Kurz Pokročilé návrhové vzory a objektové principy 2 je volným pokračováním kurzu Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací 1. Pojetím kurzu Pokročilé návrhové vzory a objektové principy 2 jsem se snažil vyhovět účastníkům předchozího kurzu, kteří mi, volně parafrázováno, říkali: "Nejlepší jsou ty části, kde probíráme jeden příklad za druhým a kde říkáte - takto to dělám já." Můj zákazník, můj pán (zvláště, jestliže se v záměrech zcela shodneme 
) - nový kurz je prošpikován příklady, tipy, kódem, vzorovými aplikacemi. Budu se těšit na oponeturu mých postupů. 
Datum konání kurzu: 9. 3. - 11. 3. 2009
Místo konání: Hotel VILLA Praha Okrajní 1, 100 00, Praha 10
U hotelu VILLA je možné parkovat, po celý den máme k dispozici wifi připojení.
Pro jistotu dodám, že na kurzu jsou samozřejmě po celý den teplé a studené nápoje a v ceně kurzu jsou obědy v hotelu.
Podrobné informace o kurzu a možnost přihlásit se na kurz
Výběr z ohlasů na předchozí kurz
Předpoklady pro absolvování kurzu:
- Znalost alespoň jednoho z rodiny "C" jazyků (C#, Java) - příklady na školení jsou v jazyce C#.
- Částečná znalost UML = neutečete zděšeni z kurzu, když zobrazím diagram tříd.
- Nenávist ke kariéře zručného klikače a zaškrtávače ve vizuálních návrhářích a "wizardech", co s velkou vášní vytváří jedno strhující uživatelské rozhraní pro číselníky za druhým.
- Vhodné, nikoliv však nutné, je i absolvovat nejdříve školení Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací 1.
Program kurzu
- Layer Supertype pro další vrstvy aplikace – vrstva pro řízení procesů a business transakcí.
- Deklarativní změny v logice procesů v nasazené aplikaci prováděné samotným uživatelem.
- Evidence historie objektů - různé přístupy.
- Vlastní správce historie pro .Net Framework a Javu.
- Řešení konkurenčního přístupu k datům.
- Optimistická konkurence - různé implementace.
- Pesimistická konkurence - různé implementace.
- Pesimistická konkurence - různé implementace.
- Konkurence napříč objektovými modelem - "Coarse grained lock" - různé implementace.
- Thread Specific Storage – vlastní řešení.
- Modelovani uživatelem zadávaných výběrových podminek (např. uživatelem definované sestavy nad objednávkami) – můj „Conditions“ vzor.
- Návrh a implementace netriviálního právového frameworku.
- Různé způsoby vyhodnocování práv - změna logiky za běhu aplikace.
- Kde všude se nám hodí myšlenky návrhového vzor Accounting - modelování business aplikací jako množiny souvisejících transakcí.
- Návrhové vzory Query a Repository a jejich vazba na „Conditions“ vzor.
- Různé přístupy k vytváření uživatelského rozhraní - Model-View-Controller, Model-View-Presenter, Passive View - můj vlastní Form Controller.
- Aplikace založené na pluginech – vzorové přístupy a doporučení.
- Správa "cizích" pluginů/služeb ve vlastních aplikacích.
- Vzor Component Configurator - správa pluginů.
- Vzor Interceptor - ukázky business aplikací, které jsou rozšiřovány za běhu aplikace s minimálním úsilím a bez strastí opakovaného nasazení aplikace.
- Kdy použít vzor Special Case?
- Remote Facade a Data Transfer Object - různé přístupy k distribuované aplikaci.
- Vzory pro zpracování požadavků na aplikaci-službu.
- Kódování vzoru Acceptor-Connector.
- Asynchronous Completion Token - vlastní pomocné objekty pro zjednodušení asynchronních úloh.
- Kódování vzoru Proactor.
- Kódování vzoru Reactor.
- Thread Safe Interface - co pro nás znamená v moderních prostředích (Java a .Net Framework)
- Co jsou takzvané “Enterprise segmenty” v business aplikacích?
- V průběhu celého kurzu - kompletní případová studie existující business aplikace, v níž jsou zakódovány postupy zmiňované na kurzu - dlouhá procházka kódem. :)
Kurz Objektovými principy a návrhovými vzory řízený design a vývoj kvalitních aplikací 1
Datum konání kurzu: 20. 4. - 22. 4. 2009
Místo konání: Hotel VILLA Praha Okrajní 1, 100 00, Praha 10
U hotelu VILLA je možné parkovat, po celý den máme k dispozici wifi připojení.
Pro jistotu dodám, že na kurzu jsou samozřejmě po celý den teplé a studené nápoje a v ceně kurzu jsou obědy v hotelu.
Organizační informace ke kurzu
Program kurzu
Výběr z ohlasů na kurz
Tuesday, 11 November 2008 16:38:10 (Central Europe Standard Time, UTC+01:00)
Analytické drobky | Kurzy UML a OOP | Návrhové vzory | UML
Tuesday, 14 October 2008
Monday, 08 September 2008
Sunday, 18 May 2008
Monday, 11 October 2004
Jak prosadit BizTalk (a SOA architekturu vůbec) u českých firem?
Pár námětů na zamyšlení pro produktové manažery v Microsoftu ohledně rozšiřování BizTalku 2004 a "evangelizaci" jeho schopností a hranic. Jedná se o moje zkušenosti z prezentace možností BizTalku u jednoho klienta a dále z obecné konzultace o integraci aplikací přes XML. Posluchači byli z vyššího IT managementu. Konzultace většinou žádné nedělám, ale o projekt na BizTalku bych měl velký zájem, takže jsem udělal výjimku.;)
Výsledky jsou ale z mého pohledu tristní.
- Největší zájem o BizTalk mají pobočky zahraničních firem, které chtějí integrovat nebo nahradit kvanta pidi aplikací na Lotus Notes.
- Někteří zákaznící si myslí, že BizTalk=XML a XML vyléčí během jednoho dne všechny potíže při výměně dat s partnery. Bez námahy, programování atd.
- Jiní zákaznící považují BizTalk za CASE nástroj pro návrh procesů, protože obsahuje Orchestration Designer!
- BizTalk je v mysli mnohých také spjat s řízením projektů. Možná by mohl Microsoft zapracovat na posílení povědomí o svých serverových produktech a prodal by minimálně pár licencí na MS Project Server.
- Také zaznělo, že BizTalk je nástroj pro vytváření OLAP kostek. Sice v něm tuto funkčnost naleznete, ale asi nikdo si nebude BizTalk kupovat jen kvůli OLAPu.
Konzultace se většinou nesly v duchu seznamování se základními principy SOA, webových služeb, "enterprise" integrace aplikací a většinu přítomných to evidentně zaujalo, hlavně když zjistili, že, jak již předtím instinktivně tušili, SOA a a potažmo BizTalk jim pomůže vyřešit jejich problémy s integrací mnoha a nejen Lotus Notes aplikací.
Pro mě je zřejmé, že potenciál k rozšiřování BizTalku v Čechách je, jen Microsoft zatím nedostatečně u zákazníků zmiňuje všechny přednosti a hlavní rysy BizTalku. A myslím, že si to tak skvělý produkt jako je BizTalk opravdu nezaslouží:(
Monday, 11 October 2004 15:57:00 (Central Europe Standard Time, UTC+01:00)
Analytické drobky | Biztalk | Ostatní
Monday, 04 October 2004
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, 04 October 2004 20:54:00 (Central Europe Standard Time, UTC+01:00)
Analytické drobky
Friday, 01 October 2004
Malá anketa o business komponentách
Již dlouhou dobu se mluví o tom, že business frameworky a komponenty se stanou standardem při vývoji aplikací, již tradičně zlevní a zjednoduší jejich tvorbu (někteří cynici si myslí, že se jedná jen o další etapu v procesu geneze nového druhu cvičené opice z programátora ;)) a budou stejně populární jako vizuální komponenty v uživatelském rozhraní. Zatím se tak nestalo, ale zajímalo by mě, o jaké komponenty byste měli zájem. Všechny komponenty by byly samozřejmě doplněny o komplexní podporu v IDE (VS.NET, Eclipse atd.), byly by dodávány s průvodci pro nejběžnější úlohy a kvalitní dokumentací - jinými slovy, šlo by o komponenty s veškerým servisem, který znáte z UI komponent.
Protože v .TEXTu neudělám anketu:(, odpovídejte prosím v komentářích.
1) Komponenta pro generování kódu vrstvy pro přístup do databáze zvládající různé způsoby mapování objektů a jejich vztahů (agregace , asociace, dědičnost...). Pozor, nejedná se o netypový mapper, jakými měly být ve VS.NET Whidbey třeba Object Spaces, ale o "inteligentní" generátor typových metod databázové vrstvy, metod pro nahrání a uložení business objektů, storovaných procedur a DDL skriptů.
2) Komponenta pro kompletní evidenci historie business objektů. Logování změn všech nebo vybraných atributů objektu, volba mezi mělkou nebo hlubokou historií objektů, zapnutí podpory historie u třídy jedním konfiguračním klíčem i po nasazení projektu, výběr mezi mnoha formáty pro ukládání historie.
3) Komponenta pro vizuální definici jakéhokoli workflow nad objekty - generování kódu pro přechody mezi stavy, vizuální definice podmínek přechodu, komunikace mezi různými stavovými automaty, validace workflow, změna průběhu workflow by byla řešena za běhu aplikace výměnou jednoho definičního souboru.
4) Jiná komponenta. Napište prosím, jakou komponentu byste potřebovali.
Díky za odpovědi.
Friday, 01 October 2004 17:10:00 (Central Europe Standard Time, UTC+01:00)
Analytické drobky | Ostatní
Sunday, 06 June 2004
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ší tranzientní 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, 06 June 2004 19:53:00 (Central Europe Standard Time, UTC+01:00)
Analytické drobky | Návrhové vzory | UML
Thursday, 27 May 2004
O MDA iniciativě, nerozhodných tazích Microsoftu a klukách na pískovišti
Dnes jsem se zúčastnil konference Vývoj celopodnikových aplikací v .NET pořádané Microsoftem a společností LBMS. Na konferenci jsem se přihlásil, protože v pozvánce byla zmínka o MDA (Model Driven Architecture) a já byl zvědavý, jestli na této přednášce bude upřesněn nebo vyjasněn z mého pohledu zdráhavý až macešský vztah Microsoftu k MDA iniciativě.
Protože konference nebyla zaměřena jen na vývojáře, Honza Šeda v úvodu shrnul hlavní výhody .Net platformy a vyzdvihl její přínosy pro segment „Enterprise aplikací". Termín „Enterprise aplikace“ je dnes chameleónskou nádobou, do které si každý s gustem naleje své myšlenky a sny o extra projektu. Já používám pracovní definici, že Enterprise aplikace jsou velmi složitá a drahá řešení, která se významně podílejí na podpoře kritických business procesů firmy a netolerují se u nich chyby ani výpadky:). Jinak řečeno, vývoj a podpora Enterprise aplikace je méně riskantní než kšeftování se zbraněmi, ale zase ne o tolik. :.) Na zbraních ale určitě vyděláte víc.:)
Dle zkušeností z jiných konferencí, kde přednášeli partneří Microsoftu, jsem měl obavu, že i tato konference bude jen zástěrkou pro propagaci produktů společnosti LBMS. Naštěstí tomu tak nebylo. Přednášející z LBMS shrnuli základní rysy a cíle MDA architektury a soustředili se na dominantní koncept PDA – rozvržení různých modelů jednoho systému na hypotetickém grafu, jehož jednou osou je míra izomorfie modelu s přirozenými pojmy z problémové domény a druhou stupeň připravenosti modelu na automatizované generování programového kódu. (Computation Independent Model, Platform Independent Model, Platform Specific Model, o Language Specific Modelu nic nezaznělo). Mapování mezi modely je řízeno exaktními pravidly, i když v přednášce jejich význam nebyl podle mě dostatečně zdůrazněn. MDA tedy nenechává například mapování z analýzy do systémového designu na naší intuici, ale vyžaduje, aby byla pravidla této „hry“ explicitně zachycena, a tím se stala kontrolovatelnými.
Firma LBMS prezentovala svůj produkt Select Component Architect podporující MDA. Hodnotit celou aplikaci zatím nemíním, protože jsme demo Select Component Studia dostali na osahání a reálná zkušenost je vždy věrohodnější než pozorování dobře drezúrovaného přednášejícího, který má instrukce, co z programu předvést, aby dychtivé publikum ohromil, a jaké nedostatky musí naopak taktně zamlčet.
Takže vztah Microsoftu k MDA je dost rozpačitý. Občas pronese silácké prohlášení o svém zklamání z UML a MDA, přičemž u MDA své zklamání spíše anticipuje nebo věští, protože mi uniká, jak se mohu zklamat v něčem, co si svoje místo ve světě softwaru teprve hledá, a jindy zase podpoří své partnery, kteří na MDA a UML vsázejí. Beru to tak, že Microsoft hraje přetahovanou se svým hlavním rivalem IBM a občas si holt umanutě dupne, aby IBM pochopila, že koupí Rational Rose nedeportuje Microsoft na periferii hlavních trendů ve vývoji softwaru. Přejme to oběma firmám, i malí vzteklí kluci na sebe silácky pořvávají, ti tvrdší s gustem přerazí o sebe i pár klacků, ale potom všichni svorně stavějí po celém pískovišti zvelebující bábovičky.
Thursday, 27 May 2004 19:43:00 (Central Europe Standard Time, UTC+01:00)
Analytické drobky
Sunday, 16 May 2004
Analytikova zkušenost s Ariadninou nití
Svět objektově orientovaného programování je plný různých doporučení, striktních zákazů, nemilosrdně vyžadovaných pravidel i dobře míněných zápisků s petrifikovanými zkušenostmi analytiků-doyenů.
Studiem dokumentace k OOP by mohl nyní jeden člověk strávit celý život a zdá se být kladem, že začínající analytik není odkázán jen na svoji invenci a nemusí stále dokola s Archimédovým výkřikem objevovat dávno známé znalosti, ale zvládne učební křivku na své cestě za téměř dokonalým návrhem (na tomto světě nemůže být nic dokonalé :)) rychleji s využitím přehršle formálních poznatků svých předchůdců. Skoro růžové vyhlídky.:)
Nakonec vždy zjistíme, že mechanická aplikace sebelepších pravidel z nás dobré analytiky neudělá a že ke každému návrhu systému musíme přistupovat s respektem, protože půjde o originál reagující na vždy jiné požadavky zákazníka. Samotný proces návrhu připomíná průchod bludištěm, ve kterém jsou lákavě svůdnou Ariadninou nití zkušenosti jiných i naše vlastní, ale nikdy si nemůžeme být jisti, že postmoderní feministka Ariadna netouží po naší smrti u Minotaura, kterým je formálně dokonalý systém zcela se míjející s reálnými a zákazníkem vyslovenými požadavky.
Po trochu delším úvodu se dostávám k samotnému tématu příspěvku. Jednou z nejdůležitějších a nejvíce akcentovaných charakteristik dobrého návrhu je striktní dodržení principu izolace změn. Většinou se tímo principem míní omezení dopadu změn při rozvoji systému na určitou komponentu nebo třídu bez zásahu do návrhu a kódu ostatních a se změnou nesouvisejících komponent aplikace. Systémy, u nichž každá změna spustí dominový efekt vynucených drobných a těžko dohledatelných úprav, dokáží zákazníkům i dodavatelům připravit těžké noci plné nočních můr o neúspěšném businessu.
Izolaci změn ale nemusíme chápat jen takto omezeně jako prostředek k snadnému rozvoji aplikace. Mnohdy je nutné vyrovnat se ihned v první verzi aplikace s rozdíly při práci s třídami na různé úrovní hierarchie dědičnosti vyplývajícími přímo z aplikace uznávaných objektově orientovaných principů a zamezit šíření zhoubného požáru v podobě duplicitního kontrolního kódu.
Představme si návrh aplikace, ve které existují tři typy produktů. Běžný produkt určený k prodeji, reklamní produkt a konkureční produkt, jímž se míni produkt prodávaný konkurenční firmou. U běžného produktu se evidují tři různé ceny (běžná prodejní cena, cena vzorku a cena, kterou má produkt, je-li předán jako kompenzace obchodníkovi za splněný objem prodeje). U reklamního produktu a konkurenčního produktu se eviduje jen běžná prodejní cena.V diagramu vytvoříme abstraktní třídu ProductBase (ze zde popsaného zadání její nutnost neplyne, ale berte ji prosím jako aplikací vynucený fakt. :) ), která bude obsahovat atribut běžná cena. Potomci ProductBase "Reklamní produkt" a “Konkurenční Produkt" žádný atribut nepřidávají. Dvě další ceny (vzorek, kompenzace) přidá potomek "Běžný produkt". Z hlediska OOP je vše správně, předek ProductBase obsahuje jen společné atributy. Ostatní části systému ale například při zakládání objednávky na produkt budou nuceny při potřebě přistupovat k cenám pro vzorek a rekompenzaci přetypovávat na potomka "Běžný produkt". Nepříjemný způsob, jak do systému zavést závislost na konkrétní třídě a ne na rozhraní a porušit tak další důležitý OOP princip. Ariadna nás poprvé zradila, protože její niť se odvíjí dvěma zcela rovnocennými směry. Pro jaký směr se rozhodnout? U tohoto systému jsem zvolil následující řešení. Produkty měly být řazeny do jednoho či více katalogů, a proto vznikla třída katalogová položka. Položky objednávky si ukazují na položku v katalogu, ne přímo na produkt. Třída katalogová položka má ve svém rozhraní všechny tři ceny. To znamená, že jako jediná v celém systému zná konkrétního potomka ProductBase, se kterým pracuje, a vrací při požadavku na konkrétní cenu buď nulu, pokud u objektu daný atribut neexistuje, nebo získá a vrátí patřičnou cenu delegací na atribut třídy "Běžný produkt". Třída objednávka neobsahuje žádný specifický kód rozlišující mezi typy produktů. Popravdě řečeno, v reálném systému pracují s potomky ještě business pravidla pro objednávky na různé typy produktů, ale ta jsou uložena mimo objekt objednávky ve speciálních "strategiích". Pravidla ověřují platnost a homogenitu položek objednávky. Ale to je opravdu vše - zbytek aplikace pracuje s produkty bez přetypovávání. Milá nerozhodná Ariadno, tentokrát jsem se z tvého ambivalentního vedení vysmekl.
Podobný případ. Když píšete aplikační logiku, která má být společná pro .Net Framework i Compact .Net Framework, brzy zjistíte, že musíte v kódu zohlednit absentující funkcionalitu v Compact .Net Frameworku. Jestliže aplikaci prošpikujete neustálými testy na platformu, nejste vývojáři, ale nejhorší programátorská spodina, pro níž je Minotaurus vysvobozením a panenské Ariadny byste se neměli ani dotknout.:) Jaký je správná postup? Vezměme si jako vzorový příklad řešení nepříjemného poznatku, že v Compact .Net Frameworku překvapivě chybí známá třída ConfigurationSettings.AppSettings pro načtení konfiguračních parametrů. Abyste mohli načíst konfigurační parametry v rámci celé aplikace jednotným způsobem, vytvoříte rozhraní s metodou GetConfigValue. Poté vytvoříte dvě implementace tohoto rozhraní . Jednu pro .Net Framework s využitím třídy ConfigurationSettings.AppSettings a jednu pro Compact .Net Framework, v níž načítání parametrů z XML souboru napíšete sami. Po spuštění aplikace je zjištěna verze operačního systému, a do proměnné, jejímž typem je rozhraní s metodou GetConfigValue, je dosazena platformně závislá implementační třída. Celá aplikace používá jen metodu GetConfigValue a žádné další testy neprovádí. Ač to tak ihned nevypadá, de facto se jedná o návrhový vzor Bridge, v němž konkrétními implementory jsou platformně závislé třídy a odstiňující abstrakcí pro klienty je rozhraní s metodou GetConfigValue. Také zde je dilema - většina OO příruček hlásá, že by v systému neměly vznikat třídy s jednou odpovědností (funktoidy). Ale zde popsané "funktoidy" jsou užitečné a pro vitální funkce sytému nenahraditelné.
Ariadnina niť se u každého kvalitního návrhu systému nenávratně přetrhne a to je většinou spolehlivý příznak, že jsme nalezli vlastní mapu k bludišti a nepotřebujeme zavádějící berličky třetích stran. Příznak toho, že jsme odborně dospěli a neuctíváme již nekriticky OO autority a jejich subjektivní a nutně počtem i typem navrhovaných aplikací podmíněně platné sentence. Včetně našich dosavadních sentencí .:)
Sunday, 16 May 2004 14:10:00 (Central Europe Standard Time, UTC+01:00)
Analytické drobky
Wednesday, 05 May 2004
Moderní architektura očima Microsoftu aneb rozpaky nad vizemi
Na konferenci, jejíž název je v titulku spotu, jsem strávil dnešní den. Microsoft na ní po úvodní přednášce prezentoval hlavně BizTalk, takže jsem ji bral jako pokračování praktického semináře z minulého týdne. Úvodní přednášku měl Michael Juřek a vysvětloval v ní, jak Microsoft reaguje na požadavky firem integrovat existující aplikace bez velkých nákladů, ale přitom způsobem, který mezi aplikacemi nevytváří více a více se svírající osudové kruhy.
Určitě osudové kruhy znáte, aplikace A využívá databázi aplikace B, ta si sáhne do databáze aplikace C pro autorizované uživatele a na oplátku v aplikaci A vyřídí faktury. Aplikace D si také ráda sosne z jiných zdrojů a máme zde solidní mikromodel chaosu. Aplikace jsou těsně provázány a přitom neexistuje jediný závazný model jejich komunikace. Ano, nebojte se, padlo i magické zaklínadlo dnešních dnů, SOA, ale kupodivu v sále hysterie nepropukla, potože Michal Juřek naštěstí nepronáší pojem SOA tak vznešeně, jak by si fanoušci buzzwords asi přáli.:) Pokud tento spot čtou šťastlivci, kteří o SOA (Service oriented architecture) neslyšeli, tak vězte, že Microsoft se přklonil k této definici služby - "Služba je autonomní část software, která implementuje logiku v podobě kódu, spravuje svůj stav, komunikuje prostřednictvím zpráv, je řízena politikou a je dostupná po síti". Když se nad touto definicí zamyslíte, tak zjistíte, že ji asi můžete napasovat na jakoukoli komponentu. Dosti žertování, bez ohledu na zbytečný humbuk kolem SOA je opravdu zřejmé, že se již dnes stále více prosazují integrace na bázi WWW služeb, u nichž nás nezajímá implementace, ale pouze struktura platformně a infrastrukturně nezávislých zpráv, které jim mohu zaslat a které mi pošlou jako odpověď. Jinými slovy, zajímá mě jen závazný protokol pro výměnu zpráv (kontrakt) mezi mnou a službou, vše ostatní je zcela irelevantní. Cílem integrací je také zrušení těsných závislostí mezi aplikacemi nasazením inteligentního prostředníka, který jejich spolupráci koordinuje. Na platformě Microsoftu je tímto integrátorem (brokerem) BizTalk.
Mimochodem - víte, kdy začnu respektovat fanoušky SOA? Až dokážou napsat WSDL WWW služby ke komponentě z hlavy - tomu říkám znalost technologie a respekt k ní:)
Nejen tato, ale i další přednášky Michala Juřka se mi líbily. Horší to bylo s částmi, které měl na starosti Miloš Sobotka. Jeho prezentace byly velmi nekonvenční, takže jsem brzy nabyl dojmu, že ho Microsoft předtím omylem vyslal na kurz asertivity místo potřebného kurzu prezentačních dovedností . Jeho ústní projev byl plný pomocných frází, zaumných přeřeknutí a rozverných anglicismů, přednáška neměla žádnou logickou kostru, prezentace dema vetšinou nedopadla podle jeho představ, ale všechnny tyto nedostatky zvládl s labilním smíchem asertivně bagatelizovat a vystavit jako přednost.:) Nebyly to informačně hodnotné přednášky, ale docela jsem se pobavil.:)
Na konci konference byly zodpovězeny naše dotazy a dostalo se i na vztah Microsotu k UML. UML 2.0 má silnou podporu pro modelování dynamického chování, a proto asi nejen mě zajímalo, jestli se v BizTalku i dalších produktech návrh procesů v UML objeví. Zvláště poté, co prosákly zprávy, že Microsoft k UML dobrý vztah nemá. Bohužel, nešlo o žádné pomluvy, Microsoft si s UML opravdu nerozumí. Já ale zase asi nerozumím Microsoftu. Jak může na konferenci o moderní architektuře bezelstně přiznat, že mu jeden z nejdůležitějších nástrojů analytika, designéra a architekta nesedí? Proč se chce vydělit z MDA iniciativy?
Oficiálně byly sděleny zatím tyto důvody pro vlažný vztah k UML.
1) UML je pro běžného vývojáře příliš komplikované. Microsoft se vždy údajně orientoval na "masového" vývojáře, který nemá žádné komplikované věci rád, a UML by tuto orientaci popřelo. Opravdu je pro Vás, kdo tento spot čtete, UML složité? A hlavně, v čem je pro Vás složité? Mně přijde jako jednoduché, čisté a elegantní. Znamená to, že JAVA vývojáří UML zvládnou, ale C# vývojář má potíže? Já myslím, že ne a že jde o pouhý alibismus kvůli bodu 2. Jsem také skeptický v tom, že Microsoft by přišel s něčím stejně výkonným jako je UML a přitom by šlo o jednodušší jazyk. Nechci hračky vhodné na splácání projektu o 10 třídách a odškrtnutí kolonky "Analýza hotova" v projektovém plánu.
2) Firma Rational Rose byla koupena IBM a IBM je konkurence, takže podpora UML by byla pro Microsoft schizofrenní. Tenhle argument už vypadá věrohodněji, protože Microsoft zcela jistě nebude podporovat konkurenci. Ale přesto, UML nepatří IBM, UML je průmyslový standard. Nevylévejte s vaničkou dítě, které má skvělé geny. A ty geny nejsou po adoptivních rodičích-vlastnících. Zásadovost je správná a konkurenci je třeba potřít, ale UML s tímhle bojem nemá nic společného. Vývojáři mohou použitím UML jen získat, ale UML je nesvede k laškování s IBM technologiemi. Věřte mi, jsem živý důkaz:)
Wednesday, 05 May 2004 20:14:00 (Central Europe Standard Time, UTC+01:00)
Analytické drobky