Návrhove vzory
SOLID
- Single responsibility principe - Každá třída jen jednu zodpovědnost. ()
- Open/Close principe - Funkcionalitu třídy lze rozšířit bez nutnosti její modifikace.
- Liskov substitution principle - Třídy musí být plně nahraditelné svými potomky.
- Interface segregation principle - Používat malá a úzce zaměřená rozhraní.
- Dependency inversion principle - Závislost na abstrakcích, nikoliv na implementacích.
GOF gang Of Four (itnetwork - karia/mat)
Creational patterns (pro vytváření)
- Factory třída k vytváření instancí jiných tříd. Vytvoř formulář, list papíru (A1). Zpravidla vrací rodičovský typ nebo rozhraní. Pokud třída kterou vrací má private konstruktor, tak nevytvoříš třídu jinak než přes konstruktor.
- Singleton - sdílení jedné instance mezi více třídami. Jinými slovy - pro globální přístup k instanci nějaké třídy. Např. s databází. Je vhodné doprogramovat aby byla thread-safe. Ale i tak je to nadoporučované a asi to plně nahradí DI
- Prototype - něco jako Factory, ale klonují se prototypy.
- Builder - pokud je toho moc (třeba parametrů) a nehodí se factory je ideální Builder. Proces generace se pak sestává z částí stavby (základy, přízemí, první patro, střecha). Pak existuje stavbyvedoucí, který celý proces kontroluje přes jednotné rozhraní. To má zpravidla workflow (příprava, začátek, kopeme, betonujeme, stavíme, začištujeme, hotovo). Jeho použití je zřejmé z příkladu:
Person person = Person.builder()
.withName("John Doe")
.ofAge(value)
.build();
Structural patterns (struktury)
- Adapter (Wrapper) - obalíme komponentu naším rozhraním. Nevadí pak že autor komponenty mění rozhraní. Většinou s databází (lze měnit různé výrobce DB) nebo Web služeb/API
- Facade (fasáda) - jednotné logické rozhraní
- Proxy (zástupce) - Remote Proxy. Nějaká funkcionalita je na vzdáleném PC, ale my to odstíníme a lze s tím pracovat jako by byl na vlastním. Virtual proxy. Nějaké zařízení co chceme používat neexistuje, ale my napíšeme simulátor. Protection proxy. K objektu lze přistupovat jen s právy, nebo některé nebezpečné funkce chceme odstínit. Smart Reference. Nějaký často používaný objekt uložíme do paměti a dále ho používáme odsud a né z hlavního objektu.
- Decorator - rozšíření funcionality bez dědění. Vhodné třeba u knihoven. Decorator zachovává původní rozhraní, ale pouze ho rozšiřuje. Např. do každého obrázku chcete vykreslit svoje logo. Rozšíříme knihovnu pro vykreslování. Pokud bychom dědili porušíme principy OOP.
- Flyweight (muší váha)
- Composite - pro práci se stromy
- Bridge - Na rozdíl od adapteru počítá s tím že se mění rozhraní na obou s stranách.
Vzory chování
- Observer (pozorovatel). - Jakým způsobem zpropagovat změnu (třeba jména) do všech metod, které to používají. Každý prvek obsahuje metodu Obnovit a jeden Observer pak projede všechny prvky.
- Strategie - jak měnit metody třeba pro výpočet slevy přímo za běhu aplikace. Teda bez dalších switch.
- Template method - zavádí kostru algoritmu. Třeba rozhraní ZapisHlavicku(), ZapisTelo(), ZapisPaticku()
- State
- Memento - návrhový vzor jak ukládat předchozí stav objektu. UNDO
- Interpreter - překladač. Z jazyka do jazyka
- Mediator - pokud spolu třídy něajk souvisí a to výrazně napřeskáčku je lepší aby komunikovaly přes jednu třídu - Mediator. Např. komunikace s formulářovými prvky. Nebo logger. Ten se pak postará kam co zapisovat.
- Iterartor - jak procházet kolekce IEnumerator
- Chain of responsibility - pomocí handleru se vyřeší nějaký složitý požadavek. Např. přijetí mailu přes metodu přijmi(). Ta volá handler přijmi() a ten zajistí kontrolu spamu, kontrolu příjemce, vyvěšení vlajky že něco přišlo, a uložení. Ale to dělá handler a né ta třída.