Mozna jsem jenom citlivka, ale posledni dobou pouzivam ruzna API zalozena pouze na design patterns a zvracim. Jdu se napit a stale zvracim. Zvracim tak, ze je od kuchynky k mymu mistu cesticka jak od hrosika liberijskeho. Procpak? Protoze jsou ta API nechutne nafoukla, pro vytvoreni jednoho objektu jich musim nesmyslne vytvorit dalsich 10 pres 20 ruznych faktories. Typickym prikladem je Eclipse.
Kam zmizela jednoduchost? Proc tolika lidem vadi prime volani konstruktoru, jednoduche pouziti objektu?
Pricina je v dablove knize od Gammovy crew pojednavajici o design patterns. Kniha samotna je samozrejme skvela, ale mela by se prodavat pouze na jakysi programatorsky zbrojni pas s varovanim na deskach.
Po jejim prelousknuti se nabuzeni ctenari snazi domenu sroubovat na patterny, pritom by meli postupovat naopak. Cim vic patternu, tim lip, pak je aplikace spravna. Kua co na tom, ze mame jenom jeden typ implementace, udelejme Abstract Factory, at se to da rozsirit. Takove programovani do supliku. Postup kompletne proti XP, kde se mysli jenom na to, jak co nejrychleji implementovat soucasny backlog.
Dalsi srandicka je pouziti nevhodneho patternu. Treba tedka s JiPim kutame do kodu jednoho milovnika patternu Visitor. Pekne a ciste naprogramovano, ale semantika aplikace place v koutku. Jde o vytvareni SQL statementu na zaklade Eclipse EMF RDB modelu. Podle Visitora existuje prave jedna visit metoda pro kazdy typ objektu. Takovy centralni mozek lidstva – CML (pozn. autora CML pochazi ze serialu Navstevnici tedy Visitors – odtud nazev patternu ). Pritom je po ohledani problemu zrejme, ze by se tu vice uplatnil Chain of Responsibility, sestaveny z autonomnich procesoru.
Pouziti design patterns nezajistuje kvalitni a jednoduchou knihovnu, coz se nekteri mylne domnivaji.
Plati takove pekne pravidlo (uz nevim od koho), kterym se da zmerit kvalita knihovny.
Kvalita knihovny se nepozna podle toho, kolik toho umi, ale naopak co vam nedovoli.
A je jednoducha.
A bez patternu. Ne, to uz kecam, jeden singleton tam byt muze. 🙂
Ach vy maloverni. 🙂 Pouziti design patterns ti usnadni komunikaci mezi programatory. Komukoliv rychleji vysvetlis design aplikace a nemusis slozite vysvetlovat za co je ktera trida zodpovedna a co dela. Stejne tak i za kratsi dobu nastudujes cizi kod.
Je pravda s pouzitim patternu kod naroste. Ale to je na uvazeni kazdeho jak a kde patterny pouzit.
Typickou ukázkou “jednoduchosti” rozhraní je DOM API.
Když to člověk srovná s XOM …
Ahoj File,
psano sice s nadsazkou, ale zdeseni z mnoha navrhovych vzoru vyzniva verohodne:)
Vidim, ze kdyz na skolenich mam i kapitolu “Kdy nepouzivat navrhove vzory” a vysvetluji nevhodna pouziti nebo kombinace vzoru a take se vysmivam mereni “kvality” aplikace a jejiho navrhu poctem obsazenych a co nejvice laskovne propletenych vzoru , ma to smysl. Tedy alespon mam duvody, proc proti takovym postupum brojit, a budu doufat, ze to ma i smysl, aby DP molochu bylo mene 🙂
ad Mnagas: s tim zlepsenim komunikace mas pravdu. Bohuzel lidi ty patterny musi znat. Zrovna minuly tyden se diskuze jednoho tymu zastavila na zbytek dne kvuli vysvetlovani Strategy (zase, jak jinak, existovala jen jedna implementace).
ad Petr: Veril bys, ze jsem v tomhle textu mel pred publikaci priklad XOM vs DOM? Zajimave 🙂
ad Rene: Mene jich asi nebude, lidi jsou zblbly. Patterns berou jako zarikavadla a oblbovaky pred skutecnym problemem domeny a kolegy.
Take mi prijde, ze pred ucenim se patternum, by se nejdrive mela venovat pozornost algoritmizaci. Co, Rene, skoleni mas? 😉
a) naučit se pořádně syntaxi jazyka – jsem se minulý týden před jednou zkouškou ve škole hodně divil, co všechno za kouzla lze provádět se zanořenými třídami/rozhraními a nemít matroš od R. Pecinovského, asi bych to nevěděl do teÄ.
b) naučit se skutečně základy algoritmizace a OOP. Lepit kusy kádu a objekty, to dokáže kde kdo
c) naučit se standardní API jazyka – můj kámoš potřeboval seřadit obyčejný List a tak z dlouhé chvíle psal a tunil quick-sort a přitom stačilo volat Collections.sort()!
d) pořádně se naučit návrhové vzory. Jedna věc je znát je, druhá věc je ovládat.
Myslím, že nejen Eclipse API je pěkně nafouknuté. DOM, díky nativní specifikaci pod IDL a snaze o univerzální portování na cokoliv, kde se vyskytuje něco alespoň trochu podobného objektům, je nafouklé až hamba. Už, abych si otestoval XOM, a nebo StAX!
Kvízová otázka: “Singleton taky není všemocný. Psal jsem teÄ semestrálku a myslím, že se mi podařilo vytvořit několik vzorových příkladů, kde rozhodně nepatří. Nebo se jen pletu?”
to Padacek: o tom je presne tenhle prispevek. Zadny pattern neni vsemocny, vsemocny je jen selsky rozum.
Hehe, tak to by vysvětlovalo občasné XxxNoSpaceError vyhazované během vývoje naší semestrálky :-/ spolubydla měl asi pravdu.