Mne C# v podstate nevadi, syntax je +- Java, funkcnost +- rovnaka, alebo trocha rozsirenejsia. Pochopi aj C++kar. Dolezity je aj tak princip.
Ale tie screenshoty kodu, to je zloba. To by musel clovek rucne prepisat aj keby to chcel skusit priamo v C#. To by som si pripadal ako v 1993tom, ked som z prirucky k Didaktiku rucne prepisoval priklady do pocitaca...
A nikde ziaden link na githubovy repozitar ani nic.
Jsem z článku poněkud rozčarován:
1. IMO je úplně jedno, jestli jde o C# nebo jiný podobný jazyk. Jde o obecný princip a ten kód je tak jednoduchoučký, že není co zkoumat.
2. Moc jsem nevyčetl, jak moc ten návrhový vzor pomáhá řešit ten složitý graf závislostí - hodilo by se nějaké srovnání.
3. Screenshoty kódu z browseru nasměrovaného na GitHub, přičemž v článku není ani odkaz do daného repozitáře?
Zcela chápu, že málokdo dosáhne kvalit materiálů, jaké zde zveřejňují pánové Tišnovský nebo Stěhule, ale tohle?
Díky za reakci. Výhrady byly dvojí - formální a obsahové, chápu, že přepsat to celé by byl opruz, ale příště bych očekával, že ten obsah bude smysluplnější - myšleno nějaký příklad na GitHubu, který se dá spustit (nemusí nic moc dělat) a ne jenom pár maličkých snippetů. Tak snad příště to bude vážně lepší.
Nezlobte se, ale ty obrazky z githubu misto zdrojaku vam poradil kdo?
Podobne by me zajimalo, proc proboha atributum rikate tridni promenne? Tridni promenne a metody patri tride, tj. v C# to odpovida statickym metodam a atributum!
V kazdem pripade ten clanek je velice spatne pojaty. Autor prijde s problemem, o kterem jen v obecnych frazich konstatuje, ze existuje, ale jiz jej nijak nedemonstruje. Pak vytahne z rukavu reseni a predvede jej na programu, ktery to reseni nepotrebuje. Podtrzeno secteno: mame tu hromadu zbytecneho kodu, ktery veci jen zeslozituje a nikdo nevi proc.
Tento pristup dela navrhovym vzorum medvedi sluzbu a to je duvod, proc je cela rada programatoru apriori odmita, resp. nechape, a proto je povazuje za zbytecnost, samoucelnou hracku, a skoro bych rekl az cargo cult.
22. 4. 2020, 12:52 editováno autorem komentáře
Dobrý den,
S články jsem ve svých začátcích. Obrázky zdrojových kódu je ode mne opravdu hloupost a do příštího článku to samozřejmě napravím.
S pojmem třídní proměnná se setkávám na denní bázi a jestli je to špatné vyjádření, poučím se.
Dále děkuji za kritiku špatného pojetí, dám si na to pro příště pozor.
Vrtalo mi hlavou jak na ten článek zareagovat, až to kolega popsal líp než bych svedl já.
Tak jen dodám, že použití daného patternu musí být ukázáno na takovém příkladu, ze kterého budou jasně vidět jeho výhody. A možná ani není potřeba se tak babrat s kódem, je to univerzální princip použitelný v jakémkoli objektovém jazyku.
I když teď když na to koukám znovu - pokud opravdu bylo smyslem článku ukázat, jak to implementovat v C#, tak to bych se snad přimlouval za nalezení nějakého vhodnějšího magazínu.
Každý vnucený “návrhový vzor” je cargo cult. Jen “vzory” (koncepty, postupy, hierarchie) přirozeně plynoucí z návrhu komplexního kódu stojí za pozornost, ať už jde o klasickou ampliativní dědičnost, proxy objekty nebo třeba bifunktory. Člověk bez rozsáhlých zkušeností z praxe by vůbec neměl používat “vzory” z knih, tím jen zadělá na problémy v budoucnu a sám se nádavkem naučí něco, čeho se pak bude jen těžko zbavovat.
Mým smyslem bylo předvést jednoduchou implementaci. Ovšem tak jednoduchá implementace zase nevystihuje, jak by mohla zjednodušit graf závislostí.
Slibuji, že příští článek projde více názory ještě před publikací a bude vypilován.
Pokusili jsme se o rychlou nápravu a to, že kód už nyní není v obrázcích.
Ukázky kódů je možné najít na těchto URL adresách:
https://gist.github.com/DannyRusnok/2e353892daf77d3a669e8f015c715304
https://gist.github.com/DannyRusnok/164d38ff6051c95dba52a8e086ef2fcb
https://gist.github.com/DannyRusnok/26e1f72b629a53609eb8969f93bec954
https://gist.github.com/DannyRusnok/e40ae62a56fcd6d50a762915739921a3
https://gist.github.com/DannyRusnok/2b14ea58bc2c3a717f00f8ee458cc1a1
Pamatuju si, že dokud jsem neznal dost z praxe, podobným teoretickým textům jsem nerozuměl - bylo to moc abstraktní.
Navrhoval bych proto udělal pokračování - druhý díl článku. Tam by mohl autor ilustrovat přínos na nějakém praktickém příkladu. Akorát by ten příklad měl sedět. Přeci jen mi přijde, že se na Mediator najde vhodný příklad hůře než třeba na MessageBus, který řeší decoupling obecněji a možná i srozumitelněji.
Pokud jde o moc závislostí, tak to je většinou problém moc složitýho modelu. A než přidávat další kód, vyplatí se popřemýšlet nad architekturou.
S jedním centrálním objektem se mě vybaví kód od jisté nejmenované kanadské firmy, kde v každým .c souboru bylo #include <headers.h> a v headers.h byly inkludovány všechny hlavičky (cca 50 souborů). Brrr.
Pekne, sam jsem ale nikdy toto nepotreboval.
IMHO je nutnost pouziti mediatoru spise znakem, ze je neco spatne v architekture programu.
Prijde mi lepsi mechanismus Spring IoC, ale rozumim, ze Spring for .Net uz zdechl. Kod je decoupled na urovni Spring konfigurace, nevznika zde rezije s predavanim zprav a ani nepotrebuju separatni notifikacni thread.
A taky osobne se vyhybam pouzivani dedeni, misto toho pouzivam interfaces s kompozici.
Dedeni pouze pokud chci rozsirovat funkcionalitu tridy o dalsi vlastnosti.