Dnes se v našem seriálu o chybách v návrhu podíváme na situace, při nichž bychom plnohodnotným využíváním typového systému zpřehlednili kód a učinili jej méně náchylným k chybám.
V dnešním příspěvku se podíváme na to, proč je dobré psát kód na jedné úrovni abstrakce (angl. single level of abstraction). Ukážeme si několik příkladů kódu, který tomuto principu nevyhovuje, poté jej upravíme a uvidíme, jaké výhody nám to přineslo.
Existuje mnoho druhů duplikace. Nejznámějším typem je duplikování kódu. Mezi další typ patří strukturální duplikace, o kterém jsem psal nedávno (Deméteřin zákon). Dneska se podíváme na další typ: duplikace znalostí a s tím související princip DRY.
Již několikrát jsem ve svých příspěvcích zmiňoval Deméteřin zákon (angl. Law of Demeter). Dnes se podíváme na to, o co jde, k čemu je to dobré a co nám to přináší.
V dalším díle našeho seriálu o chybách v návrhu se podíváme na nešvar, kterého se mnohdy nevědomky dopouštíme: místo doménových typů k reprezentaci složených dat používáme řetězce.
V dnešním díle seriálu o chybách v návrhu se podíváme na nešvar, který znepříjemňuje práci uživatelům knihoven: nekonzistentní rozhraní.
V dnešním díle seriálu o chybách v návrhu se podíváme na chyby, které objektově orientovaný kód degradují na procedurální úroveň. Zaměříme se na porušování principu "Tell, don't ask", který říká, že byste měli objektům říkat, co po nich chcete, a nikoliv se jich vyptávat a pak činit rozhodnutí za ně.
V minulém díle jsme se bavili o situacích, kdy má třída příliš mnoho odpovědností. V dnešním díle si ukážeme, jak velké problémy skrývá na první pohled příjemný a jednoduchý návrhový vzor Singleton a proč jej tak mnoho programátorů zneužívá v situacích, kde nemá co dělat.
Vítejte v prvním díle nového seriálu na mém blogu: chyby v návrhu. Budeme se zabývat častými chybami v návrhu, kterých se dopouští (nejen) začínající programátoři. Dnes si povíme něco o situacích, kdy má třída příliš mnoho odpovědností.
Na jednom týmovém sezení (při řešení projektu do předmětu Počítačová grafika) jsem nadhodil techniku známou jako Mixins. Bohužel jsem ji tehdy nedokázal dostatečně vysvětlit a její použití nebylo v dané situaci vhodné, takže bych to chtěl tímto příspěvkem napravit a ukázat, že tato technika je v praxi velice užitečná a že využití mixinů by nemělo být obecně považováno za "bad practice" či za anti-vzor.
