Differences

This shows you the differences between two versions of the page.

--- statnice:vyvoj:otazka21 [21.05.2008 17:03] – xvalo07
+++ statnice:vyvoj:otazka21 [21.05.2008 22:41] (current) – otázka dokončena xvalo07
@@ Line 20: / Line 20: @@
   * **ukrývání implementace** - tím, že jsou metody zapouzdřeny v objektu, lze měnit jejich implementaci bez dopadu na okolí, nebo třeba vytvořit třídy simulující určitou činnost. **Příklad:** třídě pro odesílání emailů řekneme co a kam má poslat, ale nezajímá nás, jakým způsobem a prostředky to udělá. Simulační třída může třeba maily jen ukládat do logu a nic ve skutečnosti neposílat.
   * **komunikace objektů** - aby mohly objekty komunikovat musí na sebe mít referenci (ukazatel). I tak má přístup jen k rozhraní objektu, zbytek je díky zapouzdření a ukrytí implementace nedostupný. tedy Objekty zpřístupňují jen to, co je nezbytně nutné pro vzájemnou komunikaci.
-  * **dědičnost** - znovupoužitelnost na úrovni deklarace třídy. Tzv. dceřinná třída (nebo potomek) může dědit metody a atributy od své rodičovské třídy (předka). K tomu může přidat nové metody, nebo změnit metody od rodiče (překrytí, předefinování) - tzv. **dynamická vazba** (late binding), kdy se vazby (děděné metody, atributy) spojí až v okamžiku běhu aplikace. Lze tak znovupoužít (svým způsobem centralizovat) chování, které je společné více třídám. Každý objekt zná svou třídu a předka (předkem všech bývá zpravidla třída Object).
+  * **dědičnost** - znovupoužitelnost na úrovni deklarace třídy. Tzv. dceřinná třída (nebo potomek) může dědit metody a atributy od své rodičovské třídy (předka). K tomu může přidat nové metody, nebo změnit metody od rodiče (překrytí, předefinování) - tzv. **dynamická vazba** (late binding), kdy se vazby (děděné metody, atributy) spojí až v okamžiku běhu aplikace. Lze tak znovu použít (svým způsobem centralizovat) chování, které je společné více třídám. Každý objekt zná svou třídu a předka (předkem všech bývá zpravidla třída Object).
   * **polymorfismus** - různé třídy mají stejné metody, se stejnými parametry a stejným sémantickým smyslem, ovšem jinou implementací. Zjednodušuje a zpřehledňuje to pochopení a samotné programování. Například: File->delete(), Directory->delete(), Email->delete(), Note->Delete().
 ==== Další pojmy ====
   * **Abstraktní metody** - volat metody potomka předkem. Předek sám metodu neimplementuje, pouze předepisuje název metody, její parametry a návratovou hodnotu, které má potomek implementovat
-  * **Abstraktní třídy** - FIXME
+  * **Abstraktní třídy** - třída obsahující abstraktní metody (ne nutně všechny musí být abstraktní). od takové třídy nelze vytvořit instanci.
-  * **Rozhraní** - FIXME
+  * **Rozhraní** - Rozhraní zaručuje uživateli, že všechny třídy, které jej implementují, obsahují implementované metody (dovednosti) tohoto rozhraní. Názvy většinou mají typu: Sortable, Comparable ...
-  * **Statické a dynamické metody a data** – statické jsou spustitelné nezávisle od existence instance metody, dynamické nikoliv – je třeba vytvořit instanci. Např. v Javě mohou být součástí jedné třídy obě, ale nemohou si vzájemně šahat na data.
+  * **Statické a dynamické metody a data** – statické jsou spustitelné nezávisle od existence instance metody, dynamické nikoliv – je třeba vytvořit instanci. Např. v Javě mohou být součástí jedné třídy obě, ale nemohou si vzájemně sahat na data.
   * **Serializace objektů** – vyjadřuje princip spojení kódu s daty. Pokud je objekt serializovatelný, „ví“ jakým způsobem uložit svůj stav a jak jej načíst zpět.
@@ Line 60: / Line 60: @@
 ===== Praxe =====
-FIXME
+  * **Rozhodněte se, zda bude nutné změnit metodiku podle OMG, nebo se naopak přizpůsobit.**
+Náš zákazník, náš pán - asi je snazší změnit notaci diagramů, než předělat vlastní firmu na jinou metodiku (která ovlivňuje způsob myšlení, postupy, výstupy ...). otázka je také, zda bude UML kompatibilní s naší metodikou (jestli pomocí UML dokážu vyjádřit vše, co naše metodika žádá). Do budoucna zvážím studium UML.
+  * **Co sdělíte svému zákazníkovi?**
+Pokusím se ho přesvědčit, že naše notace je pro daný účel vyhovující/dostačující. Vysvětlím mu, že bude lepší, když to nechá na nás, a UML se nechá vyrobit až nakonec z diagramů naší notace.
+  * **Proč, podle vašeho názoru, společnost OMG nechce přiznat specifikaci jazyka UML metodický obsah a tvrdí, že to není nic víc, nežli specifikace jazyka? Je vůbec možné úplně oddělit jazyk od metodiky?**
+Protože metodik existuje velké množství, od různých skupin (firem, sdružení, univerzit), pro různé typy projektů a dost se od sebe liší. UML je především syntaxe diagramů, pomocí které lze modelovat cokoliv, třeba jen jeden diagram jedné konkrétní části systému - proč se kvůli tomu učit a omezovat nějakou konkrétní metodikou? Navíc se sešlo hodně společností a dalo jim dost práce se shodnout na jednotné notaci. Metodiky jsou o dost rozsáhlejší, komplikovanější a dosáhnout shody je obtížnější. Raději bych viděl metodiku/návod pro tvorbu UML diagramů, které jsou úplné, správně strukturované a vzájemně konzistentní - tedy spíš nějaké best practices.