Návrhové principy II

DRY & WET

aneb suché a vlhké programování

  • Don't repeat yourself
  • Obecný princip neopakování se

    "Každý poznatek systému musí mít jedinou, jednoznačnou
    a určující implementaci"
     
  • Vztahuje se na primární zdroje informací = ty co upravují lidé
  • Nedodržení -> WET - Write Everything Twice/We edit terrible

Proč DRY?

  • Každý řádek kódu v aplikaci musí být udržován a je potenciálním zdrojem chyb
     
  • Dodržení je předpokladem pro tvorbu znovupoužitelného kódu

Důsledky nedodržení DRY

  • Zvýšený výskyt chyb - s kódem kopírujeme i chyby, při následných opravách jsme nuceni opravovat i kopie a na některé zapomeneme. 
     
  • Problematická optimalizace - kód vykonávající stejnou logiku na více místech = irelevantní výsledky profileru
     
  • (NE)čitelnost kódu - kód produkovaný dle DRY je čitelný a není problém při změně programátora.
     
  • Problematická refaktorizace - nebudou refaktorovány všechny kopie kódu

Proč nedodržujeme

DRY

  • "Rychlé" programovací metody - Clone & Modify
     
  • Nezkušenost - poučme se i z chyb ostatních ať jich nemusíme sami dělat tolik
     
  • Neexistující(špatná) dokumentace - špatná orientace v aplikačním frameworku
     
  • Špatná komunikace v týmu - hlavně neochota hledat společná řešení

Jak dodržovat DRY

  • Návrhové vzory - většin věcí které řešíme již někdo vyřešil, otestoval a zdokumentoval
     
  • Refaktorizace - refaktorujte! A refaktorujte často.
     
  • Revize kódu - kontrolujte si kód vzájemně, diskutujte o návrhu při jeho implementaci.

    •  

Ne každá duplicita je porušení DRY

  • Duplicitní kód spolu musí logicky souviset - vyjadřovat stejnou informaci.
     
  • Při "špatném dodržování" zvyšujeme provázanost kódu.

 

 

 

double cm2M(int cm) {
  return cm/100;
}

double decimal2Percent(int number) {
  return number/100;
}
result.ok=right
text.right=right

Ne vždy je třeba DRY dodržet

  • Jako ostatní principy nám má DRY ušetřit práci s údržbou kódu
     
  • bezmyšlenkovité striktní dodržování může více práce přidat než ušetřit
     
  • porušování DRY v Unit testech a HTML šablonách je obecně tolerováno

GRASP

  • sada principů pro pomoc při rozdělování zodpovědností
     
  • skládá se z 9 "principů":
    • Protected variations(chráněné změny)
    • High cohesion(vysoká soudržnost)
    • Low coupling(slabá provázanost)
    • Pure fabbrication(pouhá konstrukce)
    • Polymorphism
    • Indirection(nepřímá vazba)
    • Information expert
    • Creator
    • Controller

(General Responsibility Assignment Software Patterns)

Protected variations

  • Identifikujte místa pravděpodobných změn a zodpovědnosti přiřaďte stabilním rozhraním, která okolo nich vytvoříte.
     
  • 2 druhy změn které je třeba rozlišovat:
    • variation points - změny v rámci existujícího systému
    • evolution points - budoucí změny, neexistující v systému
       
  • Výhody: 
    • jednodušší provádění změn
    • změny neovlivní ostatní prvky
    • snížení provázanosti

High cohesion

  • míra jak moc jsou zodpovědnosti jednoho prvku související
     
  • snažíme se o zachování co nejvyšší soudržnosti
     
  • Výhody:
    • snažší pochopení prvku
    • stabilnější, méně často se mění
    • znovupoužitelnější

High cohesion
důvody nízké soudržnosti

  • příliš hrubá granularita zodpovědností - prvke zpracovává zodpovědnosti, které by měl delegovat specializovaným prvkům
     
  • postupné přidávání zodpovědností - místo vytvoření nového prvku přidáme zodpovědnost do již existujícícho


     
  • HINT: pokud hodně metod prvku používá pouze malou část instančních proměnných => pravděpodobně jde o nízkou soudržnost

Low coupling

  • míra jak moc je jeden prvek propjen s dalšími prvky
     
  • snažíme se o zachování co nejmenší provázanost
     
  • Výhody:
    • snažší pochopení prvku
    • znovupoužitelnější
       
  • Určitá míra provázanosti je normální a nezbytná
  • provázanost se standartními prvky není problém

Low coupling

  • zdroje provázanosti prvku A a B: 
    • A má atribut odkazující na B
    • A volá metodu B
    • Parameter nebo návratová hodnota A je typu B
    • A je potomkem B
    • A implementuje B

Polymorphism

  • Pokud chování závisí na typu objektu, přiřaďte zodpovědnost polymorfické metodě třídy, na které chování závisí
     
  • nikdy neřiďte chování pomocí podmínek testující typ objektu
     
  • Při nedodržení je obtížné a nebezpečné přidání každé další podtřídy
     

Pure fabrication

  • třídy pro zlepšení kvality kódu
     
  • existují odpovědnosti jejichž přiřazení třídě z domény by narušilo soudržnost třídy
     
  • měly by vznikat jen pokud ostatní řešení má jasné nevýhody.
     
  • většina návrhových vzorů je pure fabrication

Indirection

  • pokud se chcete vyhnout přímé vazbě přiřaďte odpovědnost prostřeníkovi
     
  • hlavní motivace je snižování provázanosti a dodržení protected variations
     
  • takový to prostředník představuje pure fabrication

Information expert

  • zodpovědnost přidělte expertovi(prvku), který má informace potřebné k provedení
     
  • zodpovědnost by měl mít objekt který obsahuje potřebná data
     
  • Podporuje:
    • zapouzdření
    • nízkou provázanost
    • vysokou soudržnost

Creator

  • přiřaďte třídě B zodpovědnost za vytváření A pokud:
    • ​B je agregátor objektů A
    • B obsahuje objekty A
    • B uchovává záznamy o objektech A
    • B úzce spolupracuje s A
    • B má inicializační data pro A
       
  • motivace:
    • snižování provázanosti
    • omezení míst na kterých se vytváří instance

Controller

  • odpoveď na otázku. Kdo by měl být zodpovědný za zpracování systémových událostí?
     
  • jde o pure fabrication prvek který leží mezi UI a doménovou vrstvou
     
  • UI při systémové události volá controller, který akci deleguje na další součásti systému

KISS - Keep It Simple Stupid

Vždy jednej v souladu s kontextem a okolnostmi problému. Nekombinuj co není potřeba. Nedělej složitější to co není. Navrhni vždy řešení, které je efektivní v souladu s okolními podmínkami.

DRY - Don’t Repeat Yourself

Pokud něco děláš podruhé a používáš CTRL+C a CTRL+V je něco špatně! Neduplikuj kód, pokud jde něco vytknout před závorku udělej to! Využívej principy OOP.

YAGNI - You Ain’t Gonna Need It

Nestav nic co není potřeba. Dívej se do budoucnosti v rozumném horizontu. Zvaž jestli někdy využiješ přidanou funkci, zvaž jestli ti v budoucnu spíše nezkomplikuje život.

CoC - Convention over Configuration

Drž se konvencí, usnadňuje to orientaci v kódu a snižuje nutnost znát dokonale pozadí kódu. Programátor nemusí dělat zbytečná rozhodnutí, pokud se kód chová standardně podle očekávání. Není nutné se učit všechny konfigurační direktivy a postupy jak zajistit požadované chování.