jarda jirava .net - stránky věnované .net technologii, vývoji software s pomocí .net frameworku, návrhu software a architektuře řešení krátké postřehy

přijde vám to v první chvíli docela líto. Vzápětí si však uvědomíte, že je to něco, co vás odlišuje od ostatních, že jste něčím výjimeční a že takovým vlastně chcete být. A něco takového jsem si mohl uvědomit i já na začátku tohoto měsíce.

Při té příležitosti si vzpomínám na dobu před více jak půl rokem, kdy jsem v Microsoftu seděl u kulatého stolu, kam jsem byl přizván, ještě s dalšími diskutujícími a celým tím blokem se vynula otázka: "Jak přilákat více vývojářů k .net frameworku?" Já se v té době, a i poté, již šestým rokem snažil přispět svojí troškou tím, že jsem odpovídal a pomáhal na serveru builder.cz ve fóru o .netu. Převážně začátečníkům, kteří se rozhodují zda u .netu zůstanou, ale i těm pokročilejším. A že těch otázek i odpovědí není málo, vždyť si jistě samy vzpomenete nejen na své začátky, kolik jste měli otázek - i já ještě zjišťuji, že jich je přede mnou spousta nezodpovězených.

Jednou z nich je, po začátku měsíce, i další. "Mám se raději zaškatulkovat a nepomoci tak, v konkrétním případě, asi 60% dotazujících se?" Vždyť .net framework je komplexní a pokrývající široké spektrum možností vývoje software a to od asp.net webových aplikací, přes winform desktopové aplikace, webové služby a ... takhle bych ještě chvilku mohl pokračovat. Každý začátečník má pak svůj cíl a cestu, kterou se chce vydat. Moje rozhodnutí je tedy celkem jasné, raději budu mít dobrý pocit z toho, že pomohu a ostatním ukážu .net framework z pohledu, který znám, i to že se dá .netem dobře bavit a vytvářet různorodé aplikace a vlastně nejen to, byť zřejmě přijdu o nějaké ty výhody.

Teď se určitě všichni ptáte - nejspíše skutečně všichni, až na jednoho, proč tohle vlastně píšu? Je to tak trošku proto, abych vyjádřil odeznělé pocity ze zklamání, a třeba za půl roku, za rok se dočtete a dozvíte víc. Ale spíše ne, protože se jen nerad škatulkuju.

Všem pak přeji krásné prázdniny a dovolené a zůstaňte výjimeční. :-)

než odpovídat, potom to alespoň nevypadá jako, že jste blbec, když neznáte odpověď. Mimochodem, to mi lehce připomělo báječnou hru Blbec k večeři v nastudování divadla Bez zábradlí.

Ale zpátky k tomu, o čem jsem se chtěl rozepsat. Jak jistě víte, již dlouhou dobu jsem členem komunity kolem serveru builder.cz a jeho fóra o .net. Nedávno jsem dokonce uspořádal i první neformální setkání přispěvatelů tohoto fórá, ale to už opět odcházím od tématu.

Proč je tedy lepší se ptát? Nejste totiž limitováni ničím, nejspíše řešíte problém, který zrovna pálí vás a nikoho jiného a v hlavě máte nějakou ideu. Tuto ideu se potom snažíte s větším či menším úspěchem přetransformovat v otázku a pak už jenom čekáte a říkáte si: Milé fórum, poper se s tím jak umíš. Samozřejmě je tu i druhá strana, kdy se ptáte, protože se snažíte někoho zkoušet a odpověď už dávno znáte, ale to není zrovna náš případ.

Ač nemám zrovinka rád různá přirovnání, k některým otázkám z poslední doby bych jedno takové, lehce kulhající, měl. Otázka vypadá asi následovně.

Mám dvě kola, řídítka, nějaký morot a kousek drátu se špagátem. Milé fórum, slyšel jsem, že z toho udělám auto. Bude mi stačit francouzský klíč nebo mám použít hever?

Ne ne, tohle není problém jenom u otázek, týkajících se .netu, ono se stačí podívat i do ostatních diskuzí a přijdete na ještě větší perly. O těch zase někdy příště.

Jak se také zeptat?

Některé určitě napadne otázka, jak je tedy lepší se zeptat, co je na takové otázce špatně a jak ji zlepšit. Vždyť co, vyjmenoval jsem snad vše, co bylo možné a co vím a znám.

Co mi však na takové otázce schází, možná jenom mě, je cíl, dílčí nebo konečný výsledek, našeho snažení. Tazatel vesměs všechno má, jenom neví jak to dát dohromady. Nezabývá se již otázkou, zda mu něco neschází, zda je možné se takto k výsledku dobrat, řeší už jenom konkrétní způsob a pokud možno konkrétní implementaci.

Odpovídající na straně druhé chvíli přemýšlí a snaží se podané informace napasovat někam do svých současných znalostí, takříkajíc čte mezi řádky ta nevyřčená slova a hledá za nimi hlubší smysl a význam takového snažení a nutnosti položit takto koncipovanou otázku, jenže ve většíně případů je o pověstný chlup vedle. Potom si připadá skutečně jak ten blbec.

Minulý týden jsem si přečetl příspěvek Ronnieho "Proč používat objekty - pokračování" a nedalo mi to, abych nereagoval v komentářích. Přeci jen mám trochu jiný pohled na danou problematiku vycházející z mých zkušenosti a dosavadních znalostí.

Pod článkem se rozjela fajn debata, ze které jsem poznal pohled i jiných vývojářů na používání objektů. Pokud jsem správně pochopil jejich výroky, nelíbí se jim možnost používat protected viditelnost u objektů. Konzistence a zapouzdření je pro objekty požadováno, avšak můj názor je takový, že tyto požadavky nejsou porušeny tím, že objekt zpřístupní svůj rozšířený interface svým potomkům. Znamená to, že objekt má vesměs dva (v případě .net tři) přístupné interface.

Public interface

První interface je tvořen public viditelností vlastností a metod. Tento interface je přístupný všem okolním objektům, které chtějí s naší instancí třídy komunikovat.

Rozšířený interface za pomoci protected viditelnosti

Public interface však není jediný, který může architekt zpřístupnit. Dalším a neméně důležitým je i tento interface - byť se to někomu nemusí zdát. Samozřejmě v tomto případě hodně záleží na samotném tvůrci, aby zajistil, že tento interface neporuší konzistenci objektu. To znamená, zpřístupnil pouze takový interface, který konzistenci neporuší. Nemusí se však jednat o public interface, ale pouze takový, který uvidí třídní potomci. V .net frameworku, a vesměs asi v každém propracovaném a dobře navrženém frameworku, nalezneme spoustu tříd, který zpřístupňují svůj rozšířený interface svým potomkům.

K čemu rozšířený interface použít

Napadá mě hned několik možností, při kterých návrhář třídy bude využívat tohoto rozšířeného interface k zajištění konzistence a přitom nedojde k porušení zapouzdření. Pro lepší názornost bude vhodnější uvést příklad takové třídy a jejího potomka.

Dejme tomu, že máme třídu Osoba, která má několik vlastností (atributů) a metod pro manipulaci s touto třídou. Jednou z veřejných metod je i metoda pro uložení objektu, tato metoda by měla zkontrolovat, zda je při splnění komplexnějších podmínek umožněno uložit objekt Osoba. Tyto podmínky platí i pro potomky.

V případě, že bych Osoba poskytovala pouze veřejný interface, musel by každý potomek zajistit kontrolu těchto podmínek, neboť ukládání je pro každého potomka malinko odlišné. Jak si ale v takovém případě může být autor třídy Osoba v tomto jistý? Řešení je v tomto případě zajištěno implementací návrhového vzoru Template method a tedy rozšířením interface pomocí protected metody. V takovém případě nebudeme public metodu k uložení označovat jako virtuální a po zkontrolování podmínek budeme volat protected metodu.

Taková třída tedy může vypadat následovně:

public abstract class Osoba {
public void Save() {
  if (podminkySplneny()) {
    saveInternal();
  } else {
    // zalogování informací a případné vyvolání výjimky
  }
}
protected abstract void saveInternal();
}

Tímto způsobem máme zajištěno, že objekt zůstane zapouzdřený a viditelný zůstane pouze požadovaný veřejný interface, neboť je celkem oprávněný požadavek, aby okolí nemohlo volat žádost o uložení objektu, bez kontroly splnění podmínek.

Je to jen jeden z mnoha případů, proč si myslím, že není nebezpečné používat také protected viditelnost u objektů. Ale jak jsem se již někde vyjadřoval, vše je to o konkrétním člověku. Pokud navrhnu veřejný interface špatně, může to být více nebezpečné než pokud správně navrhnu celou třídu i s rozšířeným interfacem.

Samozřejmě je to jen můj pohled na danou problematiku a nemusí to být ten nejlepší pohled, vychází však z mých současných znalostí a zkušeností. Určitě se nebudu bránit jakékoli konzultaci nebo připomínkám, neboť jenom tak je možné si utřídit poznatky a porovnat je s okolím.

Původně jsem si říkal, že takový příspěvek snad není ani nutné psát. Každý přece ví, že do konce března mají být zaplaceny daně - samozřejmě zde platí výjimky. A tak se rozpoutal nelítostný souboj portálů zaměřených na ekonomiku a finance o to, kdo nabídne lépe propracované prostředí k výpočtu daní.

Jelikož je i mojí povinností podávat daňové přiznání, využil jsem tohoto konkurečního boje a stáhl si nabízené formuláře pro výpočet daně. Nechci tím naznačit, že bych nevěřil všemožným online kalkulačkám, které se objevily. Avšak mít možnost si rovnou vytisknout potřebné formuláře a donést je ke správci příslušné daně bylo pro mě lákavější.

Využil jsem souboru, ve kterém bylo nejen daňové přiznání, ale zároveň také formuláře pro správu sociálního zabezpečení a zdravotního pojištění.

A právě v tuto chvíli se dostávám k tomu, proč je tento příspěvek zaměřen na chyby a testování - a hlavně daně. Ač jsou jistě všechny připravované soubory zpracovávány schopnými účetními firmamy, jedno jim schází. To, co pokládá každý vývojář v současné době za nutnost a to je testování a odhalování chyb. Teď se nemusíte čehokoli obávat, pokud nepatříte do stejné minoritní skupiny jako já, určitě jste daňové přiznání podali správně.

Právě však na testování krajních mezí, nebo chcete-li krajních hodnot "dojel" můj výpočet daně. Což není, jak sami jistě uznáte, vůbec potěšující zjištění - obzvláště, když mi vyšlo, že bych měl zaplatit více, než skutečně musím. Přestože jsou v zákoně tyto krajní meze již několik let, tyto kalkulačky s nimi nepracují. Přitom jak jsem následně zjistil, jejich implementace není nemožná a ani složitá - pro jistotu jsem si to ověřil u mého správce daně, který provedl kontrolu.

Je tedy na pováženou, zda tyto kalkulačky někdo testuje, nebo zda portály důvěřují svým dodavatelům. Jak se zdá, ne vždy se to může vyplatit a ztráta důvěry v tomto ohledu není příjemná. Ba co více, tyto kalkulačky pocházejí od účetních firem, kde se do nich jistě vyplňuje několik daňových přiznání, kolik tak může být postižených jedinců a je možné takovým firmám potom důvěřovat?

Testováním by tak měl projít každý software, byť se na první pohled zdá, že se jedná jen o několik málo vzorečků, na kterých není co zkazit.

Tak jsem si říkal, že už si teda něco přečtu o tom hojně diskutovaném a probíraném stream.cz, který se včera večer spouštěl. A to přímo, jak se říká, od zdroje, když už se o tom dneska vyrojilo tolik zpráviček. A ono ejhle, místo článku se objevuje chyba 404 s odůvodněním, že se měnil publikační systém. Ach jo, tak místo vánočního počtení, nic. Tak snad někdy příště.

Byl to jistě náročný den pro vývojáře Microsoftu, a ještě náročnější den pro spousty blogerů být prvními, kdo uvede, že .net 3.0 je venku a můžeme jej začít používat. Jenže je tu otázka, a co dál? Jsem spíše praktický člověk a tak moje první poohlédnutí bylo po nástrojích, které s sebou tato verze .net přinese, pro vývojáře.

Nástroje pro vývojáře

Téměř každý příspěvek vypadal totožně, čtyři odkazy a stručné, téměř oficiální, sdělění. Michal přidal ještě obrázek, což nastínilo, o jak malou změnu s posunem v major čísle se jedná.

Když jsem však procházel co vše je možné si stáhnout navíc pro vývojáře, byl jsem nemile zaskočen. Téměř žádná podpora pro tyto nové věci zde není. Je vydána jen jedna extenze pro WWF, a možnost stažení si CTP (pouze CTP?) vezre pro WPF a WCF. Docela mi také schází Expression Designery. A to jsem se ještě nepustil do studia SDK, které je určeno jen pro serverové systémy.

Marketingové postesknutí

Nemohu se pokládat za marketingového specialistu a už vůbec nemohu rozhodovat o tom, jak bude Microsoft vydávat své produkty. Určitě se dokážu smířit s tím, že tato verze nese označení .net 3.0, méně však s tím, že schází větší podpora pro vývojáře při vydání takového produktu. Byl bych určitě raději, kdybych zároveň s vydáním běhového prostředí dostal plnou podporu pro vývoj. Oželel bych jistě měsíc nebo i dva, než se takto radovat a přitom být v kotku duše smutný.