54 - Objektově orientovaný návrh (podstata OO návrhu; vstupy a výstupy OO návrhu; návrh řízený zodpovědností; principy návrhu GRASP, principy SOLID)

Question 1

Funkcionální vs. objektové paradigma

Answer 1

Funkcionální (označovaný také jako funkční, klasický, strukturovaný, procedurální, imperativní)

• základní jednotkou dekompozice složitého softwarového systému je funkce (také se používá označení proces).
• Základním modelem je diagram datových toků, který ukazuje procesy a datové toky mezi nimi.

Objektově orientovaný

• základní abstrakcí a tedy i jednotkou dekompozice je objekt.
• Složitý softwarový systém je členěn na balíky (package), komponenty nebo jiná seskupení tříd objektů, mezi kterými mohou existovat různé vztahy.
• V UML existuje řada prostředků pro objektově orientované modelování struktury a chování.

Question 2

OO návrh - podstata, vstupy výstupy

Answer 2

Podstata OO návrhu
• Nalézt třídy a interakci jejich objektů, které budou realizovat chování reprezentované případy použití při respektování omezení daných nefunkčními požadavky.
• Pro OO návrh je kritická znalost a schopnost aplikovat principy návrhu (ne znalost UML, nebo konkrétních technologií).

Vstupy OO návrhu 
	• Specifikace případů použití 
	• Doplňující specifikace 
	• Systémové diagramy sekvence (SSD) 
	• Kontrakty operací 
	• Slovník 
	• Model domény 

Výstupy OO návrhu
• diagram tříd
• diagramy interakce
• …

Návrh třı́d = proces, který zajišťuje, že třı́dy poskytujı́ chovánı́ žádané v use-case diagramu a odpovı́dajı́ návrhovým rámcům. Zahrnuje také návrh rozhranı́ a je neoddělitelný od návrhu interakcı́.

Návrh interakcı́ - rozšiřuje návrh třı́d o detaily jako jsou operace a metody, přidává sekvenčnı́ a komunikačnı́ diagramy.
- Interakce jsou realizovány jako sekvence zpráv (synchronnı́ch i asynchronnı́ch) mezi životnı́mi čarami (lifelines).

Instanciace třı́d - zabývá se otázkou, kdo volá konstruktor.

• Některé jsou vytvořeny při spuštěnı́, nekteré majı́ známého původce při překladu, ale někdy je tato vazba dynamická.
• Existujı́ pak instanciačnı́ diagramy. (prvně implementujeme ty, kteří nemají závislosti - nejsou závislé na jiné třídě (nevede z nich šipka, jen do nich))

Question 3

Návrh řízený zodpovědností - Responsibility Driven Design - RDD, law of demeter - principle of least knowledge

Answer 3

Návrh řízený zodpovědností je způsob návrhu založený na uvažování o zodpovědnostech a spolupráci + jejich přiřazování třídám.
-> Hledání množiny spolupracujících zodpovědných objektů, které zajistí splnění cílů návrhu.

• Zodpovědností se rozumí podúloha, kterou má třída nebo skupina tříd řešit.
  -> Může to být například načítání zakázek, výpočet daně nebo kopírování souborů. Každá taková zodpovědnost lze realizovat různými třídami a různými metodami.
  GRASP radí, jak jednotlivé podúlohy mezi třídy rozdělit a jak tyto součásti spolu budou spolupracovat. Výstupem jsou nejčastěji diagramy spolupráce v jazyce UML.

Postup RDD
• Požadavky specifikované jako use-case, systemove sekvenční diagramy, …
• Vytvoření doménového modelu
• Identifikace odpovědností pro každý krok v use-case
• Přiřazení odpovědnosti doménám

Odpovědnost za činnost
• dělání něčeho
• spuštění nějaké akce u jiných objektů
• řízení a koordinace akcí jiných objektů

Odpovědnost za vědomost
• privátních zapouzdřených dat
• souvisejících objektů
• věcí, které lze odvodit nebo spočítat

Law of Demeter (LoD) / Principle of Least Knowledge - každá jednotka by měla znát pouze pro ní relevantní jiné jednotky

1. Each unit should have knowledge only about other units that are “closely” related to the current unit.
2. Each unit should only talk to its friends and should not talk to strangers. 
3. Each unit should only talk to its immediate friends.

CRC štítky (class responsibility collaborator)  - pro každou třídu uděláme kartičku a na té kartičce je název třídy, seznam zodpovědností (knows its name; checkout (doing) ), 
- collaborator - jestli potřebuje nějakou třídu ke spolupráci

Question 4

GRASP - general responsibility assignment software patterns

Answer 4

GRASP (general responsibility assignment software patterns)
= sada doporučení, principů a vodítek, sloužících k vytvoření kvalitnějšího objektového návrhu.
- Princip GRASP se zaměřuje na rozdělení zodpovědností jednotlivým třídám a objektům.

(pozn. koheze = soudržnost)
Point of changes = variation points and evolution points. (will be modified in the existing system or in its future versions, respectively)
- Cooperating objects need to be protected from the changes by stable interfaces encapsulating the points of changes → protected variations.

1. Informační expert (Information Expert)  - Kdo má za co zodpovídat?  - Zodpovědnost za nějakou akci přiřaď informačnímu expertovi - tj. třídě, která má k provedení této akce nejvíce informací, a proto i zodpovědnost.

Přínos: Obvykle vede na nízkou vazbu a vysokou kohezi 
Kdy nepoužít: Někdy by použití mohlo způsobit duplikaci nebo nárůst vazeb 

2. Tvůrce (creator)  - Kdo vytváří objekty?  - třídě přiřazena zodpovědnost za vytváření instancí jiné třídy pokud platí, že ji: 
• obsahuje 
• agreguje 
• má pro ni inicializační data 
• zaznamenává 
• hodně užívá 

Přínos: Nezvyšuje vazbu, třída tvůrce velmi pravděpodobně již závisí na vytvářené třídě díky asociaci či zanoření. 
Kdy nepoužít: Jsou-li speciální požadavky, které činí vytváření složité, pak raději použít návrhový vzor Factory, resp. Abstract Factory. 

3. Řadič (Controller) - Který objekt za vrstvou GUI zpracovává požadavky (události) a koordinuje práci systému?  - Přiřaď zodpovědnost objektu, který: 
• reprezentuje celý systém (facade controlller) - vhodné pokud je jen málo operací 
• reprezentuje scénář případu užití (use case/session controller) - pokud by jediný řadič vedl k malé kohezi 

Doporučení:
• Řadič by neměl dělat mnoho - pouze deleguje a koordinuje.
• systémové operace ve vrstvě aplikační logiky ne v GUI

4. Nízká vazba (Low Coupling)  - 	Jak redukovat vliv změn? Rozdělit zodpovědnosti tak, aby nezbytná vazba byla co nejmenší. (přidělovat zodpovědnost tak, aby bylo co nejméně závislostı́)
5. Vysoká koheze (High Cohesion) - Jak nechat objekty soustředěné, srozumitelné, spravovatelné (a jako boční efekt podporovat princip Low Coupling)?
6. Polymorfismus (Polymorphism)  - Kdo je zodpovědný za chování měnící se podle typu? 
7. Pouhá konstrukce (Pure Fabrication)  - Komu přiřadit zodpovědnost pokud by její přiřazení existujícím třídám narušilo vysokou kohezi a nízkou vazbu? 
8. Nepřímost (Indirection) - Komu přiřadit zodpovědnost aby jsme se vyhnuli přímé závislosti? 
9. Chráněné změny (Protected Variations) - Jak přiřadit zodpovědnosti tak, aby změny prvků neměly nechtěný efekt na další prvky?

Question 5

SOLID

Answer 5

SOLID
5 principů OO návrhu:
• Single responsibility - každé třídě by měla být přiřazena jediná funkce/odpovědnost
- (proti GOD classes - např user management - vytvoření účtu klienta a poslání uvítacího e-mailu - to jsou 2 věci, neměly by být v 1 třídě) (pokud se věci ale mění vždy spolu, mohou být spolu - vysoká koheze)

• Open/Closed - třída by měla být otevřená rozšiřování ale uzavřená modifikaci  - (v existující třídě se jen opravují chyby, nemění se její chování aby se nerozbil kód který ji používá)  Když dělám změny v nějaké třídě (potřebuji přidat např. novou funkčnost) tak nechci aby jiná třída při používání této třídy zkolabovala. Zdědím tedy tuto třídu a upravím její chování jak potřebuji. Ta stará bude stále normálně přístupná.

• Liskov substition - klient nadtřídy musí být schopný používat libovolnou její podtřídu aniž by ji znal 

• (metody podtřídy musí fungovat stejně jako u nadtřídy aniž by klient s třídou dělal něco navíc) .
• If the class Car has a method called Break it’s vital that all subclasses breaks when the Break method is invoked. Imagine the surprise if Break() in a Ferrari only works if the switch ChickenMode is activated.• Interface segregation - klient by měl záviset jen na vlastnostech třídy, které využívá (třída bude implementovat více rozhraní)• Dependendency inversion - moduly vyšší úrovně (byznys logiky) by neměly záviset na modelech nižší úrovně ale na jejich abstrakcích
• Abstrakce by neměly záviset na detailech. Detaily by měly záviset na abstrakcích.

Question 6

RCC a ASS

Answer 6

RCC
RCC principles about package cohesion.
REP The Release/Reuse Equivalency Principle - (the granule of reuse is the granule of release)
CCP The Common Closure Principle - (classes that change together are packaged together)
CRP The Common Reuse Principle - (classes that are used together are packaged together)

ASS
ASS principles about couplings between packages and metrics. (the metrics of the package structure of a system)
zbavit se závislostí …
vytvořit rozhraní - DIP
nebo vyjmout třídy v cyklické závislosti do zvláštních balíků .. a jednotka závislosti je pak balík, takže ta změna ven se nepropaguje

ADP The Acyclic Dependencies Principle (the dependency graph of packages must have no cycles)
	zbavit se závislostí … 
	vytvořit rozhraní - DIP
	nebo vyjmout třídy v cyklické závislosti do zvláštních balíků .. a jednotka závislosti je pak balík, takže ta změna ven se nepropaguje

SDP The Stable Dependencies Principle (depend in the direction of stability)
	Metriky
	afferent couplings (Ca) .. kolik je vstupních šipek do třídy .. Kolik věcí závisí na mě?
	efferent coupling (Ce) .. kolik je výstupních šipek ze třídy .. na kolika věcech závisím?
	positional instability … I = Ce / (Ca + Ce)
	I = 1 … balík je hodně nestabilní 
	I = 0 .. balík je hodně stabilní

SAP The Stable Abstractions Principle (abstractness increases with stability) - hodně rozhraní

Command-Query separation principle

• když máme něco, co spočítám a pak se to musím dozvědět
• tak je dobré to oddělit kvůli znovupoužitelnosti ( roll(); getFaceValue() ) .. protože pak nemusím znovu počítat to roll .. prostě se na to jenom dotážu

Question 7

Návrhové vzory

Answer 7

Návrhové vzory jsou osvědčená řešenı́ typických OO problémů. Jsou popsány a katalogizovány pro snadné použitı́.

Gang of four návrhové vzory:

Creational - obalují konstruktory podle nějakých pravidel .. cílem je vytvořit objekty

• Abstraktnı́ továrna - centrálnı́ objekt pro vytvářenı́ nových objektů.
• Singleton – třı́da může mı́t jedinou instanci. Pak je možné mı́t pevný bod přı́stupu k objektu.

structural - zadefinovat strukturu tříd

• Adapter (také Wrapper) obaluje rozhranı́ třı́dy tak, aby ji bylo možné použı́t s jiným rozhranı́m - Converts one interface to another so that it matches what the client is expecting
• Fasáda poskytuje jediné rozhranı́ pro celý subsystém (několik třı́d s rozhranı́mi) - Provides a simplified interface
• Decorator - Dynamically adds responsibility to the interface by wrapping the original code

Behavioral - zadefinovat chování - vychází ze strukturálních

• Pozorovatel - observer (také Publish-Subscribe) objekty se mohou registrovat jako pozorovatelé změny stavu daného objektu.
• Řetěz zodpovědnosti zahrnuje přı́kazové objekty a zpracovávacı́ objekty, zapojené za sebou (analogie zřetězených procesorů).