U předchozího článku se už v titulku objevilo slovo „antipattern“. Jak samotný název napovídá, jde o určitý protipól návrhových vzorů, „patternů“, ovšem tentokrát v opačném smyslu, tedy „jak to nedělat“. Pojďme si taková „antidoporučení“ projít – a nezapomeňme se přepnout do módu „nadsázka povolena“.
💻 Přísnější pravidla pro Chrome rozšíření. Firefox Focus. Win10 October Update. Wi-Fi 1-6. MS Edge. Sans Forgetica. Code Week. WebP do Firefoxu. Git chyba. 📅 LinuxDays 2018.
Proč se nebát React Native a proč začít právě s ním, když už přece znáte React.
💻 Neuznávané certifikáty. Firefox Monitor. Atom 1.31. Vivadli 2.0. TypeScript 3.1. Zdrojáky MS-DOS. Modulární CSS. Videa z WebExpa 2018. Arkády v Internet Archivu. Soutěž The Catch 2018. Solod a Inrupt.
Antipatternofobie
Pěkný článek, člověk se v něm občas najde – to (ne)klidně přiznám. Jen si musím dát pozor na antipatternofobii – stav, kdy se člověk tak bojí, že jeho kód bude odpovídat nějakému antipatternu, že kvůli tomu píše pomalu a pořád se kontroluje. To by byl vlastně nový antipattern.
Pro jistotu si ale dám článek do záložek. :-)
Re: Antipatternofobie
Zkušenný/dobrý programátor voňavý kód píše automaticky, ne? :) A pokud je otestovaný, není problém ho refaktorovat.
Poltergeist
Jak se bránit „Poltergeistu“, pokud v době jeho vytváření předpokládám, že časem funkčnost přidám (a tedy vytvořím takový objekt)?
Re: Poltergeist
Jestli casem znamena za hodinu, tak to asi takovy problem nebude. Jestli casem znamena mozna v pristi verzi SW, tak je asi lepsi obejit se bez nej.
Re: Poltergeist
Nevytvářet objekty do zásoby.
Re: Poltergeist
Joshua Bloch: „When in doubt, leave it out.“ – prostě situace „někdy se tady ta složitost bude hodit“ řešit tím, že tam tu složitost přidám až teprve to skutečně bude potřeba. Ne preventivně dříve!
opisovani wikipedie
Popisovana temata povazuji za extremne dulezita, takze na jednu stranu jsem rad ze se o nich pise – na stranu druhou mi pride celkem ubohy opisovat wikipedii a vydavat to za clanek..
Re: opisovani wikipedie
preco, mne sa to na wiki hladat nechce, tu to mam pekne pokope precitane za par minut. Diki autorovi
Re: opisovani wikipedie
„hledat na wiki“?!?! to opravdu myslite vazne? zadat do vyhledavaciho okenka „wiki antipatterns“ je otazkou mene nez 5 sekund..
..nehlede na to ze pokud se o tom chci neco dozvedet, stejne musim rozkliknout odkazy z clanku – a ty me privedou hadejte kam ?
..no ale vzhledem k tomu, ze se vam to asi nebude chtit hledat, to prozradim: na popisy antipatternu na wikipedii :)
Re: opisovani wikipedie
A kdy naposledy vás něco podobného napadlo do wikipedie zadat?
Re: opisovani wikipedie
Přesně. Je dobré, že na to autor upozornil, jinak by to nikoho nenapadlo hledat..
Re: opisovani wikipedie
Souhlasím. Autor se zcela jasně netají vazbou na wiki a každá osvěta dobrá.
Musíme o těch problémech mluvit, jinak se nám těmato hnusama bude kód plíživě zanášet.
Myslím, že nestačí propagovat, jak by se to mělo dělat. Strašně důležité je pořád si opakovat, na co si dát pozor.
Re: opisovani wikipedie
Zrovna vcera, protoze tu(nebo abclinuxu?) byl nejaky clanek o programovani a presne tuhle stranku na wiki jsem vcera cetl, ale je pravda ze jsem nevedel, ze neco takoveho je popsane. Uz nekolikrat jsem se s antipatterny setkal a ani jsem to nevedel. :)
Clovek se snazi nedelat tyto veci a je dobre vedet, ze „tudy ne pratele!“ :)
Re: opisovani wikipedie
Tak si ale uvědom, kolik článků je na internetu skutečně původních, tzn. takových že autor publikuje výhradně své myšlenky a občas se na něco odkáže. Tenhle článek je shrnutí toho co je na wikipedii v Češtině. A kdyby článek nebyl, většina lidí by o antipatternech nic nezjišťovala, někteří by ani dosud nevěděli co to je. Myslím že takovéto články mají smysl, je to jako slevo-mánie. Napadlo by tě normálně zajít na Křižíkovu fontánu do Prahy, mě spíš ne, kdybych k tomu neměl jiný podnět, ale když to máš na slevo-serveru, jako nabídku a ještě k tomu se slevou, tak se někdo chytne.
Re: opisovani wikipedie
Je dobře, že se o tom píše. Já jsem třeba o některých nevěděl, že jsou pojmenované.
Ale fakt nevím, proč píše o mýc programech …
Re: opisovani wikipedie
Akorát že na Wikipedii je před spoustou těch článků několik varování (např. neutralita článku je zpochybněna, neuvádí žádné zdroje, apod.), viz http://en.wikipedia.org/wiki/BaseBean
Prostě čtenář je varován, že se tam můžou tvrdit dost pochybné věci. Naproti tomu Zdroják nám to předkládá jako fakt. Ano viděl jsem v perexu „nadsázka povolena“. Ale vidíte to sami – jakmile někdo něco napíše, byť na místo, kam může psát každý, spousta lidí tomu začne slepě věřit :-)
Re: opisovani wikipedie
A proto máme pod články diskuze, abychom se o tématu dále pobavili. A ještě lepší by bylo po diskuzi vyvodit závěry, shrnout je do nového článku nebo diplomové práce a upravit wiki včetně odkazů :)
Re: opisovani wikipedie
Ono je to celkem jedno odkud je to opsane. Z takovehleho clanecku ani z clanku na wiki z vas mistr nebude. Na to je potreba precist toho trochu vic a hlavne to zkouset v praxi. Doporucuju napr. knihu „refactoring to patterns“, z toho clovek ziska docela dobry nahled.
Re: opisovani wikipedie
Nebude z nikoho mistr, ale uvedomi si ze nejaky problemy jsou. A dost mozna si hned vybavi nejakej svuj kod. A to by mohlo stacit k tomu, aby to cloveka motivovalo dal to resit a opravit. Jiste ze ucelena publikace to vysvetli lip, ale tenhle clanek si clovek prolitne o poledni pauze a neco mu to da.
je to opisovanie
Race condition sa nehodila?
V buducnosti by bolo dobre uviest aj zdroje na tom zrojaku…
Re: je to opisovanie
Uvést zdroje? Jako napsat třeba „Tento text čerpá z popisů antipatternů na Wikipedii, a vychází proto pod licencí CC-BY-SA“? A zkusil ses podívat na konec textu?
Loop-switch sequence
Dnes ráno jsem přečetl a ani sem netušil jak rychle se s tímto setkám :D
http://demo.online-kurz.net/scripts/jscalendar/calendar.js
řádek 1595
Re: Loop-switch sequence
Myslim, ze v tomto pripade se uplne nejedna o antipattern loop-switch sequence.
Jde tu spise o velmi prehlednou a udrzovatelnou konstrukci parsovaci funkce.
Autor se urcite poucil u knihovni funkce
printf(...)a jejich derivatu, kterou programatorsky svet zna cca od roku 1970 a jeji implementaci muzete v jazyce C nalezt napriklad v<stdio.h>.Re: Loop-switch sequence
no přiznám se tak jsem kód do hloubky nezkoumal. ale opravdu může mít daná konstrukce opodstatnění. Napadá mě například počítání znaků, čísel a speciálních znaků v řetězci. Vlastně algoritmus pro frekvenční analýzu.
Re: Loop-switch sequence
Její jednoduchá verze:
<?php
$retezec_ptakovin = „neco neco blbost necojineho ptakovina“;
$res = array();
for ($i=0; $i<256; $i++) {
switch ($i) {
case 1:
$d = „neco“
break;
case 7:
$d = „necojineho“
break;
case 44:
$d = „blbosti“
break;
/* … */
default:
$d = „“;
}
if (!$res[$d]) $res[$d] = 0;
$res[$d] += substr_count($retezec_ptakovin, $d);
}
print_r($res);
?>
Verze bez switche…
<?php
$retezec_ptakovin = „neco neco blbost necojineho ptakovina“;
$hled = array(„neco“,“necojineho“,“blbost“);
$res = array();
foreach ($hled as $i => $v) {
if (!$res[$v]) $res[$v] = 0;
$res[$v] += substr_count($retezec_ptakovin, $v);
}
print_r($res);
?>
A jednotlive znaky – kdy ma for vyznam…
<?php
$retezec_ptakovin = „neco neco blbost necojineho ptakovina“;
$res = array();
for ($i=0; $i<256; $i++) {
$c = char($i);
if (!$res[$c]) $res[$c] = 0;
$res[$c] += substr_count($retezec_ptakovin, $c);
}
print_r($res);
?>
Re: Loop-switch sequence
Ano, přibližně tohle jsem chtěl napsat. Taková konstrukce se někdy veeelmi hodí, protože dokáže dobře zpřehlednit co ten kód vlastně dělá.
Re: Loop-switch sequence
Mezi antipatternem uvedeným na Wikipedii a Vámi uvedeném javascriptovém kódu je obrovský rozdíl. V prvním případě autor ví, že první parsovaná hodnota je „key“, druhá „value“ a pak následují parametry. V druhém případě je pořadí volání parsovacích funkcí libovolné.
Re: Antipatterny, smradlavý kód a Peterův princip v IT
Komu se clanek nelibi, nepochybne jeho kod spada do jednoho z bodu a jen si to nechce priznat :)…
Re: Antipatterny, smradlavý kód a Peterův princip v IT
Mě se článek extrémě líbí, protože právě dělám na projekty, který se tím hemží. Takže jsem nasadil PHP Mass detector, Copy Paste detector a snažíme se vylepšit co se dá. Jenže…
Re: Antipatterny, smradlavý kód a Peterův princip v IT
Copy Paste detector :) to je dobrej napad to je nejakej tool ? da se to pouzit na c++ ?
Re: Antipatterny, smradlavý kód a Peterův princip v IT
V TeamCity je třeba vestavěnej Duplicates Finder (pro Javu a .NET).
Re: Antipatterny, smradlavý kód a Peterův princip v IT
Doporucuju Sonar! http://www.sonarsource.org/ nejlepsi nastroj tohoto razu co znam.
Code Complete jsem nečetl,
ale nabízená definice „nekompetentního vývojáře“ mi přijde pojatá dost nešťastně. Samozřejmě, kód by měl být vždy psaný tak, aby byl co nejpochopitelnější, ale primární problém přece není v tom, že někdo použije „málo známou vlastnost jazyka“. V prvé řadě jde o to, aby v kódu bylo co nejméně závislostí na okolí, jednoznačné identifikátory, rozumné komentáře (hlavně u popisu funkcí/metod). Používání „obskurních konstrukcí“ by samozřejmě nemělo být samoúčelné, ale často vede k daleko kratšímu nebo rychlejšímu kódu. A ať se na mě nikdo nezlobí, programátor, který nerozumí svému vlastnímu programovacímu jazyku nebo mu dělá problém konstrukci najít někde v dokumentaci nebo na Internetu, by se měl nad sebou minimálně zamyslet.
Re: Code Complete jsem nečetl,
Tam je, že tyhlety konstrukce „upřednostňuje před čitelností kódu“. Namlátit dvoukilový zdroják plný triků a hacků a říct: „Kdo se v tom nevyzná, je lama, UTFG nebo jdi na ekonomku!“ je znakem určité programátorské nedostatečnosti. Pokud použití obskurní a málo známé konstrukce má svůj význam, tak kompetentní programátor k ní přidá pořádný komentář, kde vysvětlí proč je tam tohle, jaké to má důsledky atd., nebo aspoň jak se to jmenuje. Nelze spoléhat na to, že další programátor na první pohled rozpozná v kódu nějakou konstrukci, dokáže si ji pojmenovat a najít (kdyby si ji dokázal pojmenovat, tak ji asi nemusí hledat, že?) A nemusí to být špatný programátor – třeba zná jen jiné hacky a ne zrovna ten váš.
Re: Code Complete jsem nečetl,
+1
Díky za odpověď
Obecně naprostý souhlas (až na to, že hacky a „obskurní konstrukce“ bych rozhodně nesrovnával), ale chtělo by to asi pár konkrétních případů. Asi hodně záleží na jazyku; osobně mě nenapadá třeba v Pythonu (který mě z větší části živí) žádnou konstrukci (když vynechám staré třídy) konstrukce, kterou by si programátor v našem týmu mohl dovolit ignorovat a čekat, že ho v tom nechám. Na druhou stranu jsem velice přísný, co se týče přehlednosti a dokumentace kódu. Chceš použít nějakou cool feature? OK, ale ať už používáš cokoliv, chci, aby kódu pokud možno porozuměl i ten, kdo nezná kontext a zdroják vidí poprvé. Ono to většinou opravdu jde.
Re: Code Complete jsem nečetl,
Mohu se zeptat v jake kapitole popisuje nekompetentniho vyvojare? Rad bych si to precetl :)
Re: Code Complete jsem nečetl,
Text v článku vychází z http://en.wikipedia.org/wiki/Software_Peter_principle#Programmer_Incompetence Wikipedia se odvolává na kapitolu 33.3 – Curiosity (v druhém vydání).
bohužel programátorem se člověk rodí - to se nenaučíte
Tohle je sice všechno krásné, ale být dobrý programátor se nedá naučit. Buď to máte v krvi, anebo nemáte.
Řadu těch antipatternů lidé používají především proto, že to lépe neumí a i kdybychom jim v tom tisíckrát hlavu vymáchali, tak to líp nikdy nesvedou.
Re: bohužel programátorem se člověk rodí - to se nenaučíte
s tim nemohu souhlasit programovani se da naucit . Anti paterny jsou vysledkem lenosti ! Typicky magicke konstanty.
Re: bohužel programátorem se člověk rodí - to se nenaučíte
Jako gramatika, že?
Morální hazard
Morální hazard… to je antipattern z naší politické sféry, ne?:)
Re: Morální hazard
Ovšem v kombinaci s pokročilým houbovým managementem.
Další antipatterny
Ke článku bych rád doplnil další antipatterny.
Nejzákeřnější jsou ty, které jsou prezentovány jako návrhové vzory – tedy osvědčená „nejlepší“ řešení, které chytře řeší určený problém.
Na školách se vesele vyučuje např. Singleton, který je ovšem příšernou ukázkou antipatternu. Jedna instance objektu v aplikaci se dá zařídit i jinak, než že udělám privátní konstruktor a globální statickou metodu getInstance(). Stačí se domluvit, že daný objekt nebudu nikde instanciovat, ale zavolám na něm new jen jednou a budu si ho všude předávat. Takové řešení je testovatelné a nezblázním se, když takové objekty najednou potřebuju dva.
Dalším takovým je Service Locator, kterým se zabýval díl zdejšího seriálu o Dependency Injection.
Dalšími „code smelly“ jsou globální proměnné, statické atributy tříd, „statické třídy“ – tedy třída sloužící jen jako jmenný prostor pro funkce, které nemají žádnou návaznost na instanci objektu.
Nedostatečná dekompozice objektů – pokud budu mít systém s jemnější granularitou, jeho části se pak snadněji znovupoužívají. Také by se neměla využívat dědičnost tříd tam, kam nepatří.
Aleš Roubíček nedávno prohlásil, že mutable objekty jsou také anti-pattern, byl bych rád, kdyby tuto myšlenku rozvedl :)
Z manažerských anti-patternů se mi líbí Brooksův zákon, který říká, že přidáním dalších programátorů do zpožděného projektu narůstá jeho zpoždění :) A deadliny jsou vlastně taky anti-pattern :)
Re: Další antipatterny
1) Singleton: ten se vyučuje v první řadě proto, aby studenti na jednoduchém příkladu pochopili, co to návrhový vzor je. Na lepších školách zároveň řeknou, že to má i svoje úskalí a není moc dobré ho používat. Ale jako ilustrační školní příklad na pochopení smyslu návrhových vzorů je dobrý.
2) Service Locator: záleží na kontextu, s čím to srovnáváte — ve srovnání s zpraseným kódem, kde jsou stejné věci na spoustě míst, je SL spása a krok dopředu. Samozřejmě to lze dělat lépe. A opět, jako ilustrační příklad dobré.
3) „statické třídy“ jsou v pořádku, jsou to normální knihovny funkcí — a ano, třída v takovém případě plní pouzi jmenného prostoru, ale pokud chceme používat funkce (a ne jen metody) v jazyce, který funkce formálně nemá, tak je knihovní třída jasná volba.
Re: Další antipatterny
„Dalšími „code smelly“ jsou globální proměnné, statické atributy tříd, „statické třídy“ – tedy třída sloužící jen jako jmenný prostor pro funkce, které nemají žádnou návaznost na instanci objektu.“
To neni žiadny code smell, statická trieda = modul.
citujem: „Zapáchající kód vznikne i přílišným lpěním na dogmatech – například použitím složitého návrhového vzoru tam, kde by stačilo jednoduché a přímočaré řešení.“
Re: Další antipatterny
+1 Přesně tahle věta se mi hned vybavila. Bohužel to je velice rozšířená úchylka a s postiženými se většinou nedá diskutovat.
Re: Další antipatterny
Ovšem modul musí mít všechny znaky modulu a jeho fukce musejí být opravdovými funkcemi. tj. žádný sdílený stav, žádné vedlejší efekty. Čož bývá velmi zřídka k vidění, a proto to všeobecné lpění na tom, že jde o zlo.
Re: Další antipatterny
Čož bývá velmi zřídka k vidění
Proč si to myslíte?
Re: Další antipatterny
Zkušenosti, za ta léta jsem viděl soustu code base a viděl spoustu takových statických API se sdíleným stavem a side effecty, že si musím nalít dalšího panáka, když si na to vzpomenu…
Re: Další antipatterny
S první větou souhlasím. Ovšem to, že někdo něco neumí použít z toho ještě nedělá špatný postup, ne?
Re: Další antipatterny
Pokud není blbu vzdorný a umožňuje snadno dělat prasárničky, pak to z něj špatný postup dělá.
Re: Další antipatterny
Aha. A co říkáte třeba na jazyky, ve kterých jsou přístupné všechny objekty skrz na skrz? Ty by se asi měly přinejmenším zakázat, protože o nějaké „blbuvzdornosti“ nemůže být ani řeč, přitom v nich vznikají skvěle navržené programy – není někde chyba? Chorobná preventivní opatrnost by klidně mohl být další antipattern.
Re: Další antipatterny
V C# třeba považuju prakticky za jediné moduly s funkcemi statické třídy s extenzníma metodama.
Re: Další antipatterny
A přesně k tomu jsou ty návrhové vzory — knihovní třída má mít soukromý konstruktor a nikde se pak její instance nevytváří, sdílený stav ani vedlejší efekty nemá a jediné co obsahuje jsou statické metody (ve skutečnosti ony opravdové funkce) a třída je pouze modulem, jmenným prostorem.
Re: Další antipatterny
Moc zrovna nesouhlasím s tím, co tvrdíte o singletonech. Možná jde jen o použití. Singleton samozřejmě není speciální třída, ale speciální použití a pokud jde o singleton sedící za rozhraním, na kterém je metoda getInstance(), tak samozřejmě u mě má tato metoda ještě sestřičku, setInstance(), kterou mohu dosadit vlastní implementaci. Singletony mají rozhodně své opodstatnění.
To samé se Service Locátory, třeba například v mé knihovně mám vlastní implementace funkcí, které na základě jména otevřou někde stream, což může být soubor, ale i TCP spojení. Je tam rozhraní se singletonem, za ním sedí service locátor, který na základě názvu vydá patřičný objekt, který následně je použit k uspokojení požadavku. Přijde mi to jako nejčiščí řešení, protože žádná část programu následně nemusí řešit, koho se mají doptat na konkrétní implementaci služby, a všechny části jsou schopné pracovat i se službami, které v době návrhu neexistovali. Maximální flexibilita.
Re: Další antipatterny
A proč raději nepoužít vzor Strategie?
Re: Další antipatterny
Co řeší ta další metoda setInstance()? A jak se to bude chovat ve vícevláknovém prostředí (třeba webový server) ?
Singleton je prostě zlo – jediné použití, kde bych ho toleroval, je tam, kde není technicky možné injectovat závislosti (a v tom případě je oním Singletonem Service Locator).
Re: Další antipatterny
Co to je za zbytecnou otazku? To je snad jasne ne? Tenhle typ singletonu je vetsinou, nebo spis vzdycky urcen pro zajisteni sluzeb s vnejsim prostredi, ktere je vzdy jedno. Zpravidla vetsina aplikaci bezi napriklad v ramci jednoho operacniho systemu soucasne, ktery ma zpravidla jeden filesystem (i kdyz jich ma vic, ale aplikaci poskytuje jedno rozhrani) atd. Podle vaseho dotazu hadam, ze jste tak uplne nepochopil, k cemu to je.
A proc chci mit moznost to globalne zmenit? Treba proto, ze chci rozsirit moznosti vnejsiho prostredi, nebo emulovat funkce vnejsiho prostredi, ktere to prostredi genericky nenabizi
Re: Další antipatterny
To není zbytečná otázka. Takže znovu – co řeší ta metoda setInstance() ? Co dělá je jasné, ale já se ptám, co z architektonického hlediska řeší. IMHO jen zavádí další smell a případnou race condition, kdyby se nedejbože nějaká třída rozhodla tu metodu zavolat.
Třída by měla jasně deklarovat své závislosti. V C++, C#, Javě apod. by se tedy měly všechny závislosti předávat přes parametry konstruktoru (příp. přes property setter injection). Použití singletonu vede k tomu, že třída používá něco, co v konstruktoru nedeklaruje.
Pokud je například to zmiňované API operačního systému pro práci s file systemem poskytováno jako singleton, tak s tím nic nenaděláme, a v takovém případě je potřeba se této neprůhledné závislosti zbavit na vhodné úrovni.
Např. jestli by měla třída FileLogger používat API pro komunikaci s file systemem napřímo nebo jestli by měla používat nějakou non-singleton abstrakci, to už je do jisté míry otázka vkusu. Já osobně bych třeba použil to API napřímo, protože třída vyjadřuje do jisté míry tuto závislost svým jménem.
To jsou vynucené singletony, se kterými nemůžeme nic moc dělat. Ale v žádném případě bych nezaváděl vlastné singleton – je to prostě špatně.
Třídy pak jasně nedeklarují své závislosti a třída, která singleton používá, může být netestovatelná (např. když chceme v jednom kontextu spustit více testů paralelně a každá třída potřebuje singleton jinak namockovaný).
Re: Další antipatterny
Proto tvrdim, ze to moc nechapete. V jazycich zalozenych na tridach a instancich mate ke kazde instanci adekvatni automaticky vytvoreny singleton, jak vy tvrdite asi vynuceny. Ano, je to trida, s tridnimi funkcemi a promennymi, s jednou a neprepsatelnou metodou new.
Pokud to nahradim tovarnimi objekty, vzdycky chte nechte narazime na problem s tim, ze potrebujete aby vam nekdo vyrobil instanci tovarny, nebo instanci tovarny tovaren. Nakonec skoncite u singletonu. Ze ne? No minimalne na operator new, coz je vlastne singleton.
A co delat setInstance? No to co u new nikdy neudelate, mate moznost zmenit superglobalni tovarnu tovaren, treba tim, ze dodate vlastni instanci, ktera implementuje nejaka vylepseni. Ja neobhajuju objekty navrzene jako singletony. At jsou navrzene tak aby si nekdo tu superglobalni tovarnu mohl predavat v promenne a tim se vyhne tem vasim race condition… a zmene instance tovarny za behu. Ona setInstance by se taky mela volat tak jednou za cely beh, na zacatku treba jako konfigurace knihovny, nebo pri vyznamnych udalostech… prirovnal bych to treba udalosti zmeny runlevelu v linuxu
Re: Další antipatterny
> Ano, je to trida, s tridnimi funkcemi a promennymi, s jednou a neprepsatelnou metodou new.
Jak už psal jiný Ondřej, statické položky tříd a statické třídy jsou taky smell. První jmenované jsou totiž prakticky globální proměnné a druhé vytváří singleton. Proto by se neměly používat.
A metoda new se volá jen v kompozičním rootu – jak říkal Miško Hevery na jedné ze svých přednášek, tak jedním ze znaků špatně testovatelného kódu bývá přítomnost volání new někde jinde.
> Pokud to nahradim tovarnimi objekty, vzdycky chte nechte narazime na problem s tim, ze potrebujete aby vam nekdo vyrobil instanci tovarny, nebo instanci tovarny tovaren.
Ano – tomu se říká kompoziční root aneb konfigurace aplikace.
> A co delat setInstance? No to co u new nikdy neudelate, mate moznost zmenit superglobalni tovarnu tovaren, treba tim, ze dodate vlastni instanci, ktera implementuje nejaka vylepseni.
Pokud chci změnit superglobalni tovarnu tovaren, udělám to na úrovni konfigurace aplikace. Pokud by to měl dělat někdo níže odspodu, popíralo by to IoC.
> Ona setInstance by se taky mela volat tak jednou za cely beh, na zacatku treba jako konfigurace knihovny, nebo pri vyznamnych udalostech…
Než nějaké „by se mela volat“ raději navrhnu aplikaci tak, aby bylo nesnadné dostat ji do nějakého špatného stavu.
Re: Další antipatterny
Nojo, jenze cokoliv se nachazi v rootu je vlastne singleton. Takze je ekvivalentni globalni deklaraci. Jedina vyhoda mit jeden root a v nem singletony je v tom, ze si teoreticky mohu vytvorit vice rootu.
Pak je otazkou, zda zbytecne netvorime kotvy nebo poltergaisty. Ono to, „co kdyby nahodou“ pak vede k tomu ze na jednom miste obchazime pasti, ktere jsme si jinde vytvorili
Re: Další antipatterny
Užití singletonu je vlastně speciální případ service locatoru. Navíc je to lifestyle. Pokud se volání getInstance() vyskytuje více než právě jednou jde o smell. Ve spojení s IoC je implementace vzoru singleton ok.
Re: Další antipatterny
Naopak, singleton je absolutne nekompatibilni s IoC. V tom pripade jste totiz omezovan na jednu konkretni implementaci service locatoru (za predpokladu, ze nemate neco jako setInstance(), coz ale pak neni pravy singleton). Je to pak prakticky to same, jako by jste service locator nepouzili vubec a instance si delali „na miste“.
Re: Další antipatterny
No chce to asi ještě trochu představivosti praxe. Ono vám totiž vůbec nic nebrání v tom, aby singleton implementoval rozhraní, volání getInstance() bylo provedeno právě jednou v composition rootu aplikace a všude byla tato instance injektována (klidně pomocí poor man’s DI). V takovém případě máme čisté IoC, s troufám si tvrdit, že nejde o smradlavé užití Singletonu.
Pro lepší představu připojuji ukázku:
Re: Další antipatterny
Singletony jsou krasnej priklad paternu, kterej se velice rychle muze zvrhnout v antipattern . Nekolik singletonu propojenejch jako jojo poruznu rozhazenejma volanima a callbackama a clovek se pak jen divi co to vzniklo za spiders nest .
Re: Další antipatterny
Globální proměnné jsou softwarovou implementací Archimédova principu „Dejte mi pevný bod a pohnu Zemí“. A jako takové mohou mít smysl, ale samozřejmě nesmí se to s nimi přehánět nebo je používat zbytečně.
Re: Další antipatterny
Singleton se asi z nějakého důvodu jmenuje singleton a svoji fukci plní dokonale. Používá se tam kde potřebuješ mít jednu instanci a ne dvě nebo tři. To že v průběhu implementace zjistíš, že najednou potřebuješ instance dvě není problémem singletonu, ale tvůj, protože jsi tu aplikaci blbě navrhnul. Chtěl bych vidět jak bys v týmu dvaceti vývojářů všem vysvětloval co si kam mají předávat protože to není singleton, ale instance má být jenom jedna :-D
Re: Další antipatterny
Prosím, abys zamířil do zdejšího seriálu o Dependency Injection.
Re: Další antipatterny
class foo { function __construct() { if(self::$counter) { throw new LogicException( 'použij existující instanci pičo' ); } ++self::$counter; } private static $counter = 0; }Re: Další antipatterny
Je ovšem rozdíl mezi „používá se jen jedna“ a „je absolutně nemyslitelné, aby se v aplikaci objevila druhá instance“. Druhá verze je singleton (a nic jiného singleton není) a osobně si nedovedu představit případ, kdy by bylo nutné něco takového vynucovat
(a navíc se stejně často odhalí že instancí je třeba víc http://phpfashion.com/singleton-sofie-s)
Větu o týmu neberu, pokud má tým takové komunikační a programátorské problémy, tak nevím jak by mohl vůbec fungovat
heje
Ono se ale těžko programuje, když se člověk nemůže spoléhnout na to, že funkce vrátí správnou hodnotu.
Re: heje
„aniž by si to otestoval“
Po otestování se už spolehnout může, hm?
Re: heje
Tipuji to na chybu v komunikaci mezi Wikipedií, autorem článku a publikem :-). Funkce nemusí vrátit správnou hodnotu, protože může vrátit chybový stav a to i postranním kanálem (třeba readdir_r), což při neodchycení často znamená katastrofu.
Příklad: GTK+
Už párkrát jsem si říkal, že GTK+ nezveřejňuje věci, které programátoři potřebují, a musí složitě reimplementovat. To jsem ještě nevěděl, že se tomu říká Obrácení abstrakce.
https://bugzilla.gnome.org/show_bug.cgi?id=554229#c4
http://developer.pidgin.im/ticket/14245
Při ladění jsem už několikrát narazil na Poltergeist. U jednoho kuriózního nebyla kvůli chybě ve vyšší vrstvě nikdy volána velká část kódu ve vrstvě nižší, aniž si toho kdokoliv všiml (viz Skrývání chyb). Až jednoho dne jeden člověk našel v nikdy nevolaném kódu bezpečnostní chybu…
A sám se přiznávám k tomu, že jsem párkrát použil Programování metodou pokus-omyl dokonce v kombinaci s metodou Magická čísla.
Re: Příklad: GTK+
Obrácená abstrakce – od jisté doby nepoužívám private:, pouze protected:, která chrání atributy z venku, ale umožňuje přístup zevnitř, takže funkce, které zůstávají neveřejné lze případně potřeby volat poděděním objektu. Nevýhodou je, že za správné použití zodpovídá potomek a s tím souvisí i problémy související třeba s nečekaným updatem předka například v další verzi. Nicméně, pořád to má tu výhodu, že při náhlé změně se musí opravit jedno místo v programu (potomka), než kdyby různé části programu přistupovali k atributům deklarovaným public.
Private je moc restriktivní, a kolikrát proklínám programátory, že do toho zabalí deklarace, které by se mohly venku hodit.
Re: Příklad: GTK+
Třída by měla být na dědění uzpůsobená a měla by k tomu poskytovat prostředky – např. protected metody, které umožňují překrytí. protected atributy umožňují zasahování do implementace i na místech, kde to není vhodné.
Re: Příklad: GTK+
ano,to je taky antipattern, lpeni na dogmatech.Proboha proc?
Re: Příklad: GTK+
http://fabien.potencier.org/article/47/pragmatism-over-theory-protected-vs-private
Re: Příklad: GTK+
Bohuzel, kristalove koule jsou prakticky nesehnatelne. Takze vymyslenim mist, kde se bude trida v budoucnu rozsirovat je podle me zbytecna ztrata casu a vytvari akorat zbytecne kotvy
Re: Příklad: GTK+
Tendence by měla být spíš opačná: Schovat toho co nejvíc a v případě nutnosti lze restrikce změkčit.
Já se nepovažuji za dobrého programátora, ale nesnáším protected atributy. Je to zdroj zla. Dokonce ani ve třídě, která je navržená jako (nejlépe abstraktní) bázová pro dědění. Dnešní IDE vám sice řeknou, odkud proměnná pochází, ale plnit proměnnou, kterou nemám deklarovanou, je magie. O to víc mě mrzí, že je to běžné v JDK.
Re: Příklad: GTK+
Protected v jave je neco jineho nez v C++
Re: Příklad: GTK+
Vždyť ji deklarovanou máš — akorát v předkovi.
Re: Příklad: GTK+
Deklarovaná je, a to záměrně protected v předkovi. Ale (mluvím tedy o Javě) porušuje zapoudření.
EMACS
„EMACS je skvělý operační systém, kterému chybí jen použitelný textový editor“
Ta to by chtělo implementovat Vim do EMACS třeba jako plugin.
Re: EMACS
On už ten citát neplatí :-)
Hezky clanek!
Diky za tento clanek. Ja myslim, ze jestli se v nem nekdo aspon v necem castecne nenasel, tak nikdy neprogramoval, protoze vsechny tyhle „antipatterns“ jsou dusledkem bezne praxe.
Super článok
vyzerá to, že niekto písal o firme, v ktorem pracujem :) Tu by ste našli asi všetky antipatterny popísané v článku.
Původně jsem chtěl komentovat ...
… ale komentář se tak rozrostl, ze jsem si (konečně) založil blog, udělal z toho první zápisek a časem budu přidávat věci které jsem už chtěl dávno napsat.
Nenechte se odradit nazvem blogu / permalinkem (nesnáším politickou korektnost, svět je plný věcí hodných kritiky a servítky si brát nehodlám), samotný zápisek je až překvapivě uhlazený :
http://svetjeplnyblbcu.blog.root.cz/2011/06/27/obskurni_featury_my_ass/
Re: Původně jsem chtěl komentovat ...
Ideální kodér píše správný kód ve stylu
try …
try …
try …
catch nic
Na dotaz proč to tak napsal mi odpověděl – správná aplikace nesmí strašit uživatele chybami
a to je vše, drzí přátelé. :D
Re: Původně jsem chtěl komentovat ...
:D (už na to nevidím). Myslel jsem“A to je vše, drazí přátelé.“
Naprosto sedí
Takhle jsem se dlouho nenasmál :-) Největší joke je, jak to naprosto sedí na reálné situace projekty. Člověk trochu zavzpomíná na léta minulá a na některé oblíbené projekty. Super článek!