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.
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í.
