Omlouvám se za pedantství, ale JPG je formát, který se hodí výhradně pro ukládání obrázků charakteru fotek. Pro takováto uměle vytvořená data se hodí PNG nebo GIF.

Omlouvám se za pedantství, ale JPG je formát, který se hodí výhradně pro ukládání obrázků charakteru fotek. Pro takováto uměle vytvořená data se hodí PNG nebo GIF.

Komentář byl přidán dvakrát, protože při použití čárky ve jméně mě ASP upozornilo na bezpečnostní riziko a zobrazila se chybová stránka.

Dobry den,
diky za pripominku. Jsem sice v tomhle smeru naprosty diletant, takze vsechny vytky ohledne designu a grafiky takrka bez vyhrad beru :), ale tady se musim mirne branit.
CASE nastroj, ze ktereho jsem provadel export, format gif nenabizi. Format JPG byl nejmenším zlem (mohl jsem jeste diagram exportovat jako bitmapu apod.)

Rikas jenom hra :-). Tak hraju: Abstract Factory, Command a Observer

Dobry DAGI :)
Muzes jenom jeste napsat, jake tridy jsou soucasti tech vzoru.
BTW: Stoprocentne souhlasim jen s jednim vzorem (Observer), Abstract Factory - chapu, proc ji mas ve vyctu, ale cista AF v diagramu neni, Command v diagramu nevidim.

A pro vsechny: neni nutne se omezovat na GoF vzory

Na hadanky nejsem moc dobry, ale misto obeda zkusim hadat (aspon z tech GoF).
Spise zacnu u toho u ktereho jsem si celkem jisty.
Template method - MessageReceiverBase #CreateMessage
Pak jsem na vazkach, protoze se mi zda, ze onen MessageProcessor by mohl zastavat dve ulohy.
Jednak pro vzor Builder - MessageReceivePoint [Director], MessageProcessor [Builder], FilterMessageAttributeProcessor [ConcreteBuilder], kdy by vytvarel Message.
Potom take pri pouzit ve vzoru Chain of Responsibility - MessageProcessor [Handler], FilterMessageAttributeProcessor [ConcreteHandler], zde ale chybi agregace.
Mozna i Memento - aspon mi to tak pripada u Message.Values, ze by se to k tomu dalo pouzit.
Observer - jiz zmineny, diky udalosti v MessageReceiverBase
Dalsi vzory uz asi neobjevim, i kdyz zkusim jeste popremyslet.
Jarda
PS: neslo by zvetsit toto okynko? Na psani komentare to neni. Dik

Ad CreateMessage) Ano, to je dobry postreh. Metoda CreateMessage by mohla byt soucasti vzoru Template method, to byl ten muj podnet k vylepsovani diagramu. :)
Ale i ted je metoda CreateMessage sucasti jednoho (jineho GoF) vzoru.

Vzor Builder zde neni Filtrovani ani pridavani atributu neni konstrukce ruznych reprezentaci zpravy. Obe tridy (Filter i Add) predstavuji 2 vzory pro enterprise integrace aplikací (messaging).

Chain of Responsibility ne.

Memento take ne. Chybi takove charakteristiky vzoru jako skryvani implementace apod.


Se zadavanim komentaru jeste neco udelam, vim, ze se nezobrazuji dobre.
BTW: Mate IE? |Tipuji, ze spise FireFox, tam je problem s velikosti okna markantnejsi

Ten Observer viz MessageRecieverBase. Ten command byl samozrejme nesmysl. Tu Factory jsem myslel pro zrod objektu Message v ramci MessageRecieverBase resp. MessageSMTPReciever a MessageHTMLRecievr.

Ano, s Observerem souhlasim.

Zrod objektu Message nebo nektereho potomka Message, tedy rozhodnuti o presnem typu je deleggovano na podtridy - vzor Factory Method. Proto jsem Abstract Factory vzal s vyhradami. AF sice vyuziva Factory Method, ale jedním z jejích hlavních rysů je zavedeni rozhrani pro VZNIK RODINY PŘÍBUZNÝCH OBJEKTŮ, což se zde neděje.

Jinak výborné postřehy. Přidá někdo další? ;)

BTW: Okno pro komentar by ted melo byt vetsi ...

Diky, takhle se pise o neco lepe. No nepotesil jste (jsi?) me, ale cekal jsem to (pro ChoR urcite, pro memento take, i kdyz uz jsem podobny pripad videl, pravda, neni to presne).
Ale zkusim to obracene, spise nez odpovedi se zeptam otazkou. MessageReceiverBase a jeho potomci, nemohli by byti soucasti Strategy patternu? Pak by bylo na MessageReceivePointu, aby si vytvoril prislusny Receiver.
Jinak na to, ktereho jineho vzoru by mohla byt protected metoda CreateMessage soucasti jsem neprisel, kazdopadne budu rad za dalsi rozsireni obzoru.
Jarda

Urcite si muzeme tykat;)
Ano, MessageReceiverBase a potomky lze povazovat za participanty navrhoveho vzoru Strategy, protoze zapouzruji komunikaci po urcitem protokolu. Pak MessageReceivePoint je logickou adresou, ktera k "bindovani" na fyzicky port vyuziva ruzne "strategie".
Presto bych rekl, ze spise nez o vzotu Strategy bychom mohli hovorit o jinem vzoru.

Jak jsem psal vyse, metoda CreateMessage patri ke vzoru Factory Method

Muj tip:

Intercepting Filter.

S trochou fantazie bych videl MessageReceivePoint jako Intercepting Filter. MessageReceivePoint obsahuje jedinou instanci tridy MesageReceiveBase. Tato instance vyvola udalost OnMessageReceived coz pravdepodobne zpusobi zavolani vsech zaregistrovanych instanci tridy MessageProcesor. Podle signatury metody ProcessMessage by se dalo soudit, ze by se mohlo jednat o Intercepting Filter (metoda ocekava Message a zaroven Message vraci). Co mi ale chybi k uplnemu zaveru je nejaky zpusob, jak si precist vyslednou Message pote co Message projde vsemi filtry.

Ahoj Petre,
ano, model by slo na Intercepting filter rozsirit - to je zajimavy namet na rozsireni.