Rozdíly

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

--- statnice:si:a4m33nms3 [2011/06/01 16:52]
vlk
+++ statnice:si:a4m33nms3 [2025/01/03 18:29] (aktuální)
@@ Řádek 49: / Řá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 64: / Řádek 75: @@
 === Rychlý přehled ===
-Information Expert 	rozdělení zodpovědnosti na základě přístupu k informací
+**Information Expert** 	rozdělení zodpovědnosti na základě přístupu k informací \\
-Creator 	nalezení vhodného místa k vytváření instancí
+**Creator** 	nalezení vhodného místa k vytváření instancí\\
-Controller 	realizace uživatelské akce
+**Controller** 	realizace uživatelské akce\\
-Low Coupling 	minimální závislosti mezi třídami
+**Low Coupling** 	minimální závislosti mezi třídami\\
-High Cohesion 	maximální soustředěnost souvisejících dat a funkcí
+**High Cohesion** 	maximální soustředěnost souvisejících dat a funkcí\\
-Polymorphism 	odlišné chování podle konkrétního typu objektu
+**Polymorphism** 	odlišné chování podle konkrétního typu objektu\\
-Protected Variations 	identifikace a stabilizace společného rozhraní několika tříd
+**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
+**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
+**Indirection** 	komunikace mezi dvěma třídami zajištěná třetím prostředníkem\\
 === Podrobnější popis ===
@@ Řádek 125: / Řádek 136: @@
 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, 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.1306939976.txt.gz · Poslední úprava: 2025/01/03 18:25 (upraveno mimo DokuWiki)

Nahoru