Objektově orientovaný návrh software, metodiky objektového návrhu, postupy rozvinutí technické specifikace na úrovni modulů do detailního objektového návrhu, návrhové vzory (design patterns).(A4M33NMS)

• výhody OO přístupu a podpora v programovacích jazycích (objektové, hybridní)
• metodika jako nástroj pro zvládnutí komplexity
• o fázi návrhu (kdy je prováděn, jaký je jeho účel)
• návaznost návrhu an analýzu (upřesňování, rozšiřování)
• přístup různých metodik k návrhu (agilní vs. vodopád - iterace), design je neustále refaktorován
• MDA a generování kódu z modelů, granularita návrhu
• vzory GRASP jako obecná doporučení
• vzory GOF a jejich vztah ke GRASP vzorům
• architektonické vzory layers, klient-server, request/reply, publisher/subscriber, messaging, file exchange, shared database, RMI, SOA, ESB, pipes & filters
• návrhové UML diagramy, technická specifikace, revize návrhu
• návrh (architektura) musí odpovídat funkčním a nefunkčním požadavkům (škálovatelnost, bezpečnost, stabilita, snadná údržba)
• logická a fyzická architektura (komponent diagrams, deployment diagrams)
• objekty (metody, atributy), abstrakce, zapouzdření, skládání, delegování, polymorfismus
• CASE nástroje

Z odpovědi Kouby vyplývá, že je z těch otázek nadšen zhruba stejně jako my (nedělal je on, dostal je i s předmětem přiděleny). Potvrdil, že to, kam to směřujeme, je patrně správně…ale také neví, co tím autor vlastně myslel (což asi nevěděl ani autor sám…).

Klíčová část odpovědi k metodikám OOP návrhu:

„RUP bych tam okrajově zmínil, ale souhlasím s Vámi, že je to především metodika vývoje SW. Začal bych funkčníma požadavkama, use casama, řekl bych, že se v use casech identifikují kandidáti na analytické třídy. Jak se zpřesňují use casy, tak se začíná analyzovat interakce mezi těmito návrhovými třídami, které se vyjadřují interakčními diagramy (t.j. sekvenčními nebo activity) popř. stavovým diagramem, který se typicky používá k popisu životního cyklu těch tříd. Jdyž máme takto nadefinované funkční požadavky, uděláme z analytických tříd třídy návrhové a při implementaci třídy implementační.“

• Dědičnost
• Polymorfismus
• Delegace
• Zapouzdření
• Abstrakce
• Kompozice
• Objekty

Deméterovo pravidlo je doporučení pro objektový návrh, které respektuje princip minimální znalosti o zbytku systému. Jedná se také o návod, jak kontrolovat, že implementace metod zbytečně nezvyšuje zatížení tříd dalšími třídami, které nejsou pro její funkci bezpodmínečně nutné. Objekt by měl činit jen minimální předpoklady o struktuře a chování objektů ostatních. Toho lze dosáhnout tak, že bude každý objekt komunikovat jen se svým nejbližšími sousedy, kde sousednost dvou objektů znamená schopnost jednoho objektu volat metody objektu druhého. Pravidlo Deméter tedy primárně slouží k zachování znovupoužitelnosti.

Formálně pravidlo Deméter říká, že metoda M objektu O může volat metody jen a pouze těchto objektů:

  objektu O
  parametrů metody M
  objektů vytvořených v metodě M
  objektů obsažených v objektu O

V praxi to znamená, že když máme v nějaké metodě objekt, tak voláme pouze metody poskytnuté tím objektem a nevoláme explicitně např.jeho vnořené objekty a jejich metody. Tj. něco podobného není doporučeno: this.getSomeObject().getSomeSubObject().callMethod(), nebo také someObject.getSubObject().callMethod().

• Grasp
• SOLID
• Top-down decomposition
• Bottom-up konstrukce sw (znovupouzitelne komponenty)

Převzato z http://voho.cz/wiki/objektovy-navrh-grasp/

GRASP (general responsibility assignment software patterns) je 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 se na rozdělení zodpovědností jednotlivým třídám a objektům.

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

Information Expert rozdělení zodpovědnosti na základě přístupu k informací
Creator nalezení vhodného místa k vytváření instancí
Controller realizace uživatelské akce
Low Coupling minimální závislosti mezi třídami
High Cohesion maximální soustředěnost souvisejících dat a funkcí
Polymorphism odlišné chování podle konkrétního typu objektu
Protected Variations identifikace a stabilizace společného rozhraní několika tříd
Pure Fabrication návrh univerzálních tříd, které nejsou závislé na řešeném problému
Indirection komunikace mezi dvěma třídami zajištěná třetím prostředníkem

Princip information expert (informační expert) říká, že třídou zodpovědnou za nějakou akci má být právě ta třída, která má k provedení této akce nejvíce informací. Taková třída se nazývá informační expert. Podle tohoto pravidla by se měly služby umisťovat k souvisejícím atributům a třída by měla se svými vlastními daty pracovat pokud možno sama.

Princip creator (tvůrce) pomáhá najít vhodné místo, kde vytvářet nové instance nějaké třídy. Je to princip důležitý, protože vytváření nových objektů patří mezi nejčastější operace v objektově orientovaném programování. Vytváření nových instancí třídy A by mělo být zajištěno třídou B, právě když platí alespoň jeden z těchto výroků:

• třída B obsahuje třídu A
• třída B se skládá z třídy A
• třída B obsahuje všechny informace nutné k vytvoření třídy A
• třída B velmi úzce spolupracuje s třídou A

Třída označovaná jako controller (ovladač) je taková třída, která jako první zpracovává systémovou událost (například uživatelskou akci vyvolanou kliknutím na tlačítko) a zajišťuje její provedení. Controller by měl akci delegovat specializovanému podsystému nižší úrovně.

Princip low coupling (nízká závislost) si vynucuje dodržování těchto zásad:

• nízká závislost mezi třídami
• žádný nebo minimální dopad změny jedné třídy na třídy ostatní
• vysoký potenciál znovupoužití

Princip high cohesion (vysoká soudržnost) je založen na těchto principech:

• funkce každé třídy je snadno pochopitelná a popsatelná
• každá třída do sebe soustředí data a s nimi související funkce
• existence každé třídy je objektivně odůvodnitelná

Chování se mění na základě typu objektu.

Princip protected variations (chráněné variace) ochraňuje prvky systému před změnami jiných prvků tak, že zavede rozhraní. Konkrétní chování se pak zvolí na základě konkrétní instance objektu.

Třída označovaná jako pure fabrication v systému existuje jen a pouze proto, aby vylepšila systémovou architekturu (zmenšila závislost a/nebo zvýšila soustředěnost). Taková třída je velmi vhodným kandidátem pro znovupoužití, tedy pro přenos mezi projekty se stejnou či podobnou architekturou.

Princip zvaný indirection (nepřímost) snižuje závislost mezi dvěma třídami tak, že jejich vazby přetrhne a místo nich nechá obě třídy komunikovat přes prostředníka. Tím se mimo jiné zvyšuje i znovupoužitelnost obou tříd.

Příkladem dobrého použití tohoto principu je vytvoření controlleru jako prostředníka pro přenos dat mezi uživatelským rozhraním (view) a datovým modelem (model) v architektuře MVC (model-view-controller).

Převzato z http://voho.cz/wiki/objektovy-navrh-solid/

SOLID (single responsibility, open-closed, Liskov substitution, interface segregation, dependency inversion) je sada doporučení, principů a vodítek, sloužících k vytvoření kvalitnějšího objektového návrhu. Principy SOLID shromáždil a popsal Robert C. Martin kolem roku 2000.

S Single responsibility principle Každá třída má právě jednu zodpovědnost.
O Open/Closed principle Funkcionalitu třídy lze rozšířit bez nutnosti její modifikace.
L Liskov substitution principle Třídy musí být plně nahraditelné svými potomky.
I Interface segregation principle Používat malá a úzce zaměřená rozhraní.
D Dependency inversion principle Závislost na abstrakcích, nikoliv na implementacích.

Princip jedné zodpovědnosti říká, že každá třída či modul by měl mít právě jednu zodpovědnost a tato zodpovědnost by měla být danou třídou či modulem plně pokryta. Za zodpovědnost se zpravidla považuje nějaká rozumně jednoduchá a oddělená funkcionalita. Použití tohoto principu snižuje složitost systému a zvyšuje jeho soudržnost. a pochopitelnost

Princip Open/Closed říká, že by každá softwarová entita (třída, modul, metoda, kód…) měla být otevřená pro rozšíření, ale uzavřená pro modifikaci. To znamená, že by mělo být možné změnit její chování bez toho, aby se zasáhlo do jejího zdrojového kódu. Takový zásah totiž přináší mnoho možných obtíží a komplikací. Většina realizací tohoto principu spočívá v použití dědičnosti.

Liskov substitution principle hovoří o vzájemném nahrazování dvou tříd. Je-li třída B potomkem třídy A, pak musí být třída B použitelná všude, kde je vyžadována třída A bez toho, aniž by o tom nadřazená třída věděla. Tento princip opět implikuje použití dědičnosti a polymorfizmu.

Princip oddělení rozhraní říká, že každé rozhraní by mělo být co nejmenší možné třídy by neměly být nuceny používat rozhraní, která nepoužívají.

Pokud tedy nějaké rozhraní přesáhne rozumnou velikost, musí se rozdělit do několika dalších a užších rozhraní. Potom se touto změnou zasažené třídy přepracují tak, aby implementovaly jen minimální potřebnou podmnožinu z původního rozhraní.

Princip inverze závislosti říká, že moduly na vyšší úrovni by neměly záviset na modulech nízkoúrovňových. Oba by měly záviset na abstrakcích. A dále, abstrakce by neměly záviset na implementačních detailech, ale naopak – detaily by měly záviset na abstrakcích.

Pokud například vyšší úroveň provádí nějaká rozhodnutí a jejich realizací pověřuje moduly na úrovni nižší, může se po změně nižší úrovně změnit funkce i vyšší úrovně. To by se ale nemělo stát – snižuje to znovupoužitelnost vysokoúrovňových modulů, které by měly stát odděleně od modulů nízkoúrovňových.

• GOF creational/structural/behavioral (singleton, adapter, proxy, abstract factory, visitor, MVC, compound…)

Návrhový vzor (Design Pattern) je určitý obecný návrh, jak psát kód řešící danou část problematiky (pojmenované a popsané řešení typického problému). Ve většině případů se návrhové vzory týkají OOP (Objektově Orientovaného Programování). Návrhový vzor není žádnou hotovou knihovnou nebo implementací v nějakém konkrétním programovacím jazyce. Návrhový vzor je jen popis v obecném algoritmickém zápise (i pomocí UML diagramů), který lze poměrně snadno převést do konkrétního programovacího jazyka.

Existuje jakýsi katalog základních návrhových vzorů (tzv. GoF) - celkem 23 rozdělených do 3 kategorií (dnes existuje další množství vzorů, mnoho z nich spočívá v kombinaci či pozměnění těch 23 základních). GoF se jim říká proto, že jejich základ položila skupina 4 vývojářů - Gang Of Four (GoF).

Kategorie návrhových vzorů:

• Creational Patterns (vytvářející)
  • Řeší otázky vytváření a předávání referencí objektů v systému. Umožňují ovlivnit způsob vytváření objektů (upřednostňují flexibilní objektovou kompozici namísto „pevné“ dědičnosti.)
  • příklady: Singleton, Abstract Factory, Builder, Prototype

• Structural Patterns (strukturální)
  • Popisují jak jsou třídy a objekty složeny do větších struktur.
  • příklady: Adapter, Decorator, Proxy, Facade, Composite

• Behavioral Patterns (chování)
  • Věnují se rozdělení funkčnosti a zodpovědnosti mezi objekty, komunikaci mezi objekty.
  • Observer, Command, Iterator, Strategy, Template Method