Differences

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

--- statnice:vyvoj:otazka21 [18.05.2008 11:02] – xvalo07
+++ statnice:vyvoj:otazka21 [21.05.2008 22:41] (current) – otázka dokončena xvalo07
@@ Line 13: / Line 13: @@
 ===== Teorie =====
-Základní principy:
+==== Charakteristiky OOP ====
+  * **používání abstrakce** - objekty v IS reprezentují zjednodušené objekty reality - mají pouze atributy a metody významné pro běh/používání toho IS. Rozdělení systému (aplikace) do různě abstraktních vrstev přispívá k mentální zvládnutelnosti problému.
+  * **existence objektů** - objekt je uzavřená struktura, má svojí z vnější neviditelnou paměť (atributy, data), své metody, které s tou pamětí vykonávají nějakou činnost, může obsahovat další objekty a umí přijímat a zpracovávat zprávy z vnějšku. Objekt má svou identitu, existenci (může existovat více objektů se stejnými hodnotami atributů a metodami, a přece jsou to dva odlišné objekty).
+  * **definování tříd objektů** - třída je abstrakcí objektů se stejnými vlastnostmi (atributy, metodami). Objekty téže třídy mají stejný sémantický význam. Třída je jakási šablona pro tvorbu objektů - hovoří se pak o objektu třídy, o instanci.
+  * **zapouzdření** - data a funkce jsou spojeny do jediné entity, jsou chráněna před zásahem zvenčí, a jejich vnitřní struktura tak navenek nikoho nezajímá (nemusí a nemůže zajímat).
+  * **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 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().
-Existence tříd a jejich objektů – objekty instance – každý objekt jedinečný svým identifikátorem (i když mají stejná data). Pro objekt je specifická existence datového rozhraní, což je jediné, s čím může uživatel komunikovat. Všechno ostatní je dokonale zapouzdřeno, takže nevidíme dovnitř. To umožňuje, aby vývojář změnil funkcionalitu nějakého objektu, aniž by to mělo dopad na okolí aplikace (pokud přitom neovlivní výstupy, což se téměř určitě stane). Zatímco funkce ve strukturovaném programování jsou bezestavové – závisí na vstupu a výstupu, objekty mají vlastní paměť a jsou stavové. Jediný přístup k vnitřním datům je přes metody rozhraní. To umožňuje udržet vnitřní konzistenci dat a přispívá k bezpečnosti a spolehlivosti aplikace. Abstrakce je dalším obecným postupem – je společný pro SP i OOP a díky ní se nemusíme zabývat detaily, které nás na té které vrstvě vůbec nezajímají – přispívá k mentální zvládnutelnosti problému. Dědičnost je další elementární vlastností OOP – potomci mohou dědit vlastnosti svých předků, ty měnit nebo rozšiřovat a to aniž by byl znám zdrojový kód předka – používá se k tomu, tzv. pozdní vazba, kdy se vazby spojí až v okamžiku běhu. Každý objekt ale ví čí je a jakého je typu. Každý objekt může používat metody a data předka, pokud nejsou označeny jinak. Lze i obráceně – volat metody potomka předkem – abstraktní metody. Objekty komunikují – mají standardní rozhraní, přes které si mohou předávat zprávy. Polymorfismus – princip možnosti volání stejných metod potomka, které ale u různých tříd potomků dělají něco jiného – přirovnání k vypínači světla a vypínači na sporáku. Znovupoužitelnost je další vlastností OOP. Prakticky všechny vytvořené entity – pokud je nepsalo pako – jsou znovupoužitelné v jiné aplikaci, verzi, atd. Znovupoužitelnost lze využít vytvořením instance nebo děděním.
+==== 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** - třída obsahující abstraktní metody (ne nutně všechny musí být abstraktní). od takové třídy nelze vytvořit instanci.
+  * **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ě 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.
-Rozhraní.
+=== Realizace OOP v Javě ===
+  * **dědičnost** má pouze jednonásobnou - potomek může dědit pouze od jedné třídy
+  * další metody lze získat implementací libovolného počtu **rozhraní**
+  * **zapouzdření** je možné na více úrovních, viditelnost lze povolit
+    * private - pouze pro třídu
+    * protected - pro balíček (v rámci jednoho namespacu) a potomky
+    * public - pro všechny.
+  * **polymorfismus**
+    * overloading - přetěžování metod - více metod stejného jména v jedné třídě, ale s různými parametry a implementacemi
+    * overwriting - překrývání metod - potomek nahradí metodu předka vlastní imlementací - metodou stejného jména, se stejnými parametry ve stejném pořadí a stejnou návratovou hodnotou
-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.
+==== Výhody OOP ====
+  * díky zapouzdření může být objekt odpovědný za svůj vnitřní stav a hlídat jeho konzistenci (povolené stavy a jejich změny)
+  * znovupoužitelnost zdrojového kódu, ale i částí analýzy a návrhu - prostřednictvím instancí tříd, děděním, celými komponentami ...
+  * znovupoužitelnost vede k úspoře při vývoji, změnách a opravách, zvyšuje přehlednost/srozumitelnost systému
-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.
+==== Vývoj v OOP ====
+Efektivnost programátorské práce v OOP je vysoká – problém se dá velmi dobře členit do samostatných jasně ohraničených součástí. Dá se používat jiných, už hotových částí kódu nebo je modifikovat (ve strukturovaném programování lze prakticky pouze využívat knihovní funkce – všechno nebo nic). Udržování vnitřní konzistence pomocí zapouzdření vede k omezení rizika chyb. Na druhou stranu mají objekty větší systémovou režii a to jak co do použití paměti, tak i do rychlosti zpracování.
-Objektová architektura je úzce spjata s architekturou komponentní, nicméně nesouvisejí spolu přímo (komponenty mohou být používány i strukturovaně, i když je to trochu přes ruku.)
+Jednak existují metodiky, které UML využívají jako jazyk pro vyjádření svých postupů (UP, RUP), ale především UML je pouze syntaxe k vizualizaci nějakého stavu – i když každý její element obsahuje jisté metodické postupy. UML je ale nezávislé na metodice, pomocí které se modeluje.
+==== Rozdíly oproti strukturovanému programování ====
+  * Zatímco funkce ve strukturovaném programování jsou bezestavové – závisí na vstupu a výstupu, objekty mají vlastní paměť a jsou stavové.
-Výjimky v objektovém přístupu – některé jazyky hybridní (ObjectPascal), některé se snaží o úplnou objektovost – Java, C#. Stejně se jim to moc nedaří – Java – existence primitivních typů, C# to samé + existence struktur, polí, logických a binárních operátorů.
+==== Ostatní ====
+  * Objektová architektura je úzce spjata s architekturou komponentní, nicméně nesouvisejí spolu přímo (komponenty mohou být používány i strukturovaně, i když je to trochu přes ruku.)
-Efektivnost programátorské práce v OOP je vysoká – problém se dá velmi dobře členit do samostatných jasně ohraničených součástí. Dá se používat jiných, už hotových částí kódu nebo je modifikovat (ve strukturovaném programování lze prakticky pouze využívat knihovní funkce – všechno nebo nic). Udržování vnitřní konzistence pomocí zapouzdření vede k omezení rizika chyb. Na druhou stranu mají objekty větší systémovou režii a to jak co do použití paměti, tak i do rychlosti zpracování.
+  * Výjimky v objektovém přístupu – některé jazyky hybridní (ObjectPascal, PHP), některé se snaží o úplnou objektovost – Java, C#. Stejně se jim to moc nedaří – Java – existence primitivních typů, C# to samé + existence struktur, polí, logických a binárních operátorů.
-Jednak existují metodiky, které UML využívají jako jazyk pro vyjádření svých postupů (UP, RUP), ale především UML je pouze syntaxe k vizualizaci nějakého stavu – i když každý její element obsahuje jisté metodické postupy. UML je ale nezávislé na metodice, pomocí které se modeluje.
 ===== 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.