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

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