Rozdíly

Zde můžete vidět rozdíly mezi vybranou verzí a aktuální verzí dané stránky.

--- statnice:si:a4m33nms3 [2011/05/27 16:27]
malejpavouk
+++ statnice:si:a4m33nms3 [2025/01/03 18:29] (aktuální)
@@ Řádek 17: / Řádek 17: @@
    * objekty (metody, atributy), abstrakce, zapouzdření, skládání, delegování, polymorfismus
    * CASE nástroje
+== Poslal jsem mejl Koubovi, kam to cely smeruje (mickapa1) ==
+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í."
 ===== Koncepty OOP =====
@@ Řádek 29: / Řádek 49: @@
+==== Deméteřino pravidlo ====
+Deméteřino pravidlo (law of Demeter) 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()''.
 ===== Postupy rozvinutí technické specifikace na úrovni modulů do detailního objektového návrhu =====
@@ Řádek 35: / Řádek 66: @@
    * Top-down decomposition
    * Bottom-up konstrukce sw (znovupouzitelne komponenty)
+==== GRASP ====
+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).
+=== Rychlý přehled ===
+**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\\
+=== Podrobnější popis ===
+== Information expert ==
+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.
+==Creator==
+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
+== Controller ==
+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ě.
+== Low coupling ==
+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í
+== High cohesion ==
+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á
+==Polymorphism==
+Chování se mění na základě typu objektu.
+==Protected Variations==
+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.
+==Pure Fabrication==
+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.
+==Indirection==
+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).
+==== SOLID ====
+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.
+===Rychlý přehled===
+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. \\
+===Podrobnější popis===
+==Single responsibility principle==
+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
+==Open/Closed principle==
+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==
+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.
+==Interface segregation principle==
+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í.
+==Dependency inversion principle==
+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.
 ===== Návrhové vzory =====
-   * GOF creational/structural/behavioral (singleton, adapeter, proxy, abstract factory, visitor, MVC, compound...)
+   * GOF creational/structural/behavioral (singleton, adapter, proxy, abstract factory, visitor, MVC, compound...)
+==== GoF - Návrhové vzory ====
+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

statnice/si/a4m33nms3.1306506447.txt.gz · Poslední úprava: 2025/01/03 18:25 (upraveno mimo DokuWiki)

Nahoru