Principy programovac´ıch jazyk˚u …pub.eyim.net/ziraficka/IPP-II-ESF-1_1_hyperlinks.pdfPrincipy programovac´ıch jazyk˚u aobjektovˇeorientovan´eho programov´an´ı IPP –

Principy programovacıch jazykua objektove orientovaneho programovanı

IPP – IIStudijnı opora

Zbynek Krivka, Dusan Kolar

Ustav informacnıch systemuFakulta informacnıch technologiı

VUT v Brne

Kveten ’03 – Unor ’08

Verze 1.1

Tento ucebnı text vznikl za podpory projektu ”Zvysenı konkurenceschopnosti IT odbornıku – absolventupro Evropsky trh prace“, reg.c. CZ.04.1.03/3.2.15.1/0003. Tento projekt je spolufinancovan Evropskymsocialnım fondem a statnım rozpoctem Ceske republiky.

Abstrakt

Objekty jsou vsudyprıtomnymi stavebnımi bloky jak realneho tak virtualnıho sveta.Zamerenı se na objektove orientovanou tvorbu systemu vsak dosahlo masivnıho rozsırenı azv nedavnych 90. letech minuleho stoletı. I presto se stale jedna o velmi modernı principyvyuzıvane nejen pri tvorbe softwarovych produktu, ale i libovolnych jinych systemu. Proto masmysl se tomuto stylu myslenı naucit a pochopit jeho zakladnı koncepty i pokrocile vlastnosti.

Tato publikace je zamerena predevsım na popis programovacıch jazyku, ktere tvorı komu-nikacnı most mezi clovekem a vypocetnı technikou, tudız i na objektovou orientaci budemenahlızet z pohledu systemovych analytiku a programatoru, jejichz zakladnımi nastroji jsouv teto oblasti objektove orientovane jazyky, prostredı a dalsı nastroje podporujıcı objektoveorientovany prıstup k analyze, navrhu a implementaci pozadovaneho systemu.

Venovano Mirkovi

Vrele dıky vsem, kdo nas podporovali a povzbuzovali pri praci na teto publikaci.

Obsah

1 Úvod 51.1 Koncepce modulu . . . . . . . . . . . . . . . . . . . . . 81.2 Potřebné vybavení . . . . . . . . . . . . . . . . . . . . 9

2 Principy objektově orientovaných jazyků 112.1 Základní charakteristika . . . . . . . . . . . . . . . . . 13

2.1.1 Historie . . . . . . . . . . . . . . . . . . . . . . 142.1.2 Základní pojmy . . . . . . . . . . . . . . . . . . 142.1.3 Základní koncepty OOP . . . . . . . . . . . . . 152.1.4 Model výpočtu . . . . . . . . . . . . . . . . . . 182.1.5 Výhody a nevýhody OOP . . . . . . . . . . . . 19

2.2 Datové a řídící abstrakce . . . . . . . . . . . . . . . . . 202.2.1 Třídně orientované jazyky . . . . . . . . . . . . 202.2.2 Prototypově orientované jazyky . . . . . . . . . 30

2.3 Závěr . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342.4 Studijní literatura . . . . . . . . . . . . . . . . . . . . . 36

3 Formalismy a jejich užití 373.1 Formální základ popisu objektově orientovaného jazyka 393.2 ς-kalkul . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.2.1 Syntaxe a sémantika ς-kalkulu . . . . . . . . . . 403.2.2 Příklady . . . . . . . . . . . . . . . . . . . . . . 42

3.3 UML - formální vizuální jazyk . . . . . . . . . . . . . . 443.3.1 Výhody a nevýhody formálního návrhu . . . . . 45

3.4 Závěr . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4 UML 474.1 Co je to UML? . . . . . . . . . . . . . . . . . . . . . . 494.2 Modelování v UML . . . . . . . . . . . . . . . . . . . . 49

4.2.1 Stavební bloky . . . . . . . . . . . . . . . . . . 504.2.2 Diagramy tříd a objektů . . . . . . . . . . . . . 514.2.3 Další diagramy UML . . . . . . . . . . . . . . . 56

4.3 Závěr . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

i

5 Vlastnosti objektově orientovaných jazyků 635.1 Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655.2 Poznámka ke klasifikaci jazyků . . . . . . . . . . . . . . 65

5.2.1 Pojmy . . . . . . . . . . . . . . . . . . . . . . . 655.2.2 Klasifikace jazyků . . . . . . . . . . . . . . . . . 66

5.3 Vlastnosti třídních jazyků . . . . . . . . . . . . . . . . 685.3.1 Řízení toku programu . . . . . . . . . . . . . . 685.3.2 Jmenné prostory . . . . . . . . . . . . . . . . . 685.3.3 Modifikátory viditelnosti . . . . . . . . . . . . . 685.3.4 Přetěžování metod . . . . . . . . . . . . . . . . 695.3.5 Vícenásobná dědičnost . . . . . . . . . . . . . . 695.3.6 Rozhraní . . . . . . . . . . . . . . . . . . . . . . 715.3.7 Výjimky . . . . . . . . . . . . . . . . . . . . . . 735.3.8 Šablony . . . . . . . . . . . . . . . . . . . . . . 745.3.9 Systémy s rolemi . . . . . . . . . . . . . . . . . 76

5.4 Poznámky k implementaci OOJ . . . . . . . . . . . . . 785.4.1 Manipulace se třídami . . . . . . . . . . . . . . 785.4.2 Virtuální stroj . . . . . . . . . . . . . . . . . . . 805.4.3 Poznámka o návrhových vzorech . . . . . . . . . 82

5.5 Zpracování - analýza, vyhodnocení, interpretace, překlad 835.5.1 Překladač . . . . . . . . . . . . . . . . . . . . . 835.5.2 Interpret . . . . . . . . . . . . . . . . . . . . . . 84

5.6 Závěr . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

6 Závěr 89

Rejstřík 91

Literatura 97

ii

1

Notace a konvence použité v publikaci

Každá kapitola a celá tato publikace je uvozena informací o čase,který je potřebný ke zvládnutí dané oblasti. Čas uvedený v takovétoinformaci je založen na zkušenostech více odborníků z oblasti a uvažuječas nutný k pochopení prezentovaného tématu. Tento čas nezahrnujedobu nutnou pro opakované memorování paměťově náročných statí,neboť tato schopnost je u člověka silně individuální. Příklad takovéhočasového údaje následuje.Čas potřebný ke studiu: 2 hodiny 15 minut

Podobně jako dobu strávenou studiem můžeme na začátku každékapitoly či celé publikace nalézt cíle, které si daná pasáž klade za cílvysvětlit, kam by mělo studium směřovat a čeho by měl na konci studiadané pasáže studující dosáhnout, jak znalostně, tak dovednostně. Cílebudou v kapitole vypadat takto:Cíle kapitolyCíle kapitoly budou poměrně krátké a stručné, v podstatě shrnujícíobsah kapitoly do několika málo vět či odrážek.

Poslední, nicméně stejně důležitý údaj, který najdeme na začátkukapitoly, je průvodce studiem. Jeho posláním je poskytnout jakýsi ná-vod, jak postupovat při studiu dané kapitoly, jak pracovat s dalšímizdroji, v jakém sledu budou jednotlivé cíle kapitoly vysvětleny apod.Notace průvodce je taktéž standardní:Průvodce studiemPrůvodce je často delší než cíle, je více návodný a jde jak do šířky,tak do hloubky, přitom ho nelze považovat za rozšíření cílů, či jakýsiabstrakt dané stati.Za průvodcem bude vždy uveden obsah kapitoly.

Následující typy zvýrazněných informací se nacházejí uvnitř ka-pitol či podkapitol, a i když se zpravidla budou vyskytovat v každékapitole, jejich výskyt a pořadí není nijak pevně definováno. Uvedenílogické oblasti, kterou by bylo vhodné studovat naráz je označeno slo-vem „Výklad“ takto:

Výklad

Důležité nebo nové pojmy budou definovány a tyto definice budoučíslovány. Důvodem je možnost odkazovat již jednou definované pojmy,a tak významně zeštíhlet a zpřehlednit text v této publikaci. Příkladdefinice je uveden vzápětí:

2

Definice 0.0.1 Každá definice bude využívat poznámku na okrajiDefinice!k tomu, aby upozornila na svou existenci. Jinak je možné zvětšenýokraj použít pro vpisování vlastních poznámek. První číslo v číselnéidentifikaci definice (či algoritmu, viz níže) je číslo kapitoly, kde senacházela, druhé je číslo podkapitoly a třetí je pořadí samotné entityv rámci podkapitoly.

Pokud se bude někde vyskytovat určitý postup či konkrétní algo-ritmus, bude také označen, podobně jako definice. I číslování bude mítstejný charakter a logiku.

Algoritmus 0.0.1 Pokud je čtenář zdatný v oblasti, kterou kapitolaAlgoritmus!či úsek výkladu prezentuje, potom je možné přejít na další oddíl stejnéúrovně.

Přeskoky v rámci jednoho oddílu však nedoporučujeme.

V průběhu výkladu se navíc budou vyskytovat tzv. řešené příklady.Jejich zadání bude jako jakékoliv jiné, ale kromě něj budou obsahovati řešení s nástinem postupu, jak je takové řešení možné získat. V pří-padě, že by řešení vyžadovalo neúměrnou část prostoru, bude vhodnýmzpůsobem zkráceno tak, aby podstata řešení zůstala zachována.

Řešený příkladZadání: Vyjmenujte typy rozlišovaných textů, které byly doposudv textu zmíněny.Řešení: Doposud byly zmíněny tyto rozlišené texty:

• Čas potřebný ke studiu

• Cíle kapitoly

• Průvodce studiem

• Definice

• Algoritmus

• Právě zmiňovaný je potom Řešený příklad

V závěru každého výkladového oddílu se potom bude možné setká-vat s opětovným zvýrazněním důležitých pojmů, které se v dané částiNěkteré informace mo-

hou být vypíchnuty čidoplněny takto bokem.

vyskytly, a případně s úlohou, která slouží pro samostatné prověřeníschopností a dovedností, které daná část vysvětlovala.

3

Pojmy k zapamatování

• Rozlišené texty

• Mezi rozlišené texty patří: čas potřebný ke studiu, cíle kapitoly,průvodce studiem, definice, algoritmus, řešený příklad.

Úlohy k procvičení:Který typ rozlišeného textu se vyskytuje typicky v úvodu kapitoly.Který typ rozlišeného textu se vyskytuje v závěru výkladové části?

Na konci každé kapitoly bude určité shrnutí obsahu a krátké re-sumé.ZávěrV této úvodní stati publikace byly uvedeny konvence pro zvýrazněnírozlišených textů. Zvýraznění textů a pochopení vazeb a umístěnízvyšuje rychlost a efektivnost orientace v textu.

Pokud úlohy určené k samostatnému řešení budou vyžadovat ně-jaký zvláštní postup, který nemusí být okamžitě zřejmý, což lze odhalittím, že si řešení úlohy vyžaduje enormní množství času, tak je možnénahlédnout k nápovědě, která říká jak, případně kde nalézt podobnéřešení, nebo další informace vedoucí k jeho řešení.

Klíč k řešení úlohRozlišený text se odlišuje od textu běžného změnou podbarvení čiohraničením.

Možnosti dalšího studia či možnosti, jak dále rozvíjet danou téma-tiku, jsou shrnuty v poslední nepovinné části kapitoly, která odkazuje,ať přesně či obecně, na další možné zdroje zabývající se danou proble-matikou.Další zdrojeOblasti, které studují formát textu určeného pro distanční vzdělá-vání a samostudium, se pojí se samotným termínem distančního čikombinovaného studia (distant learning) či tzv. e-learningu.

4

Kapitola 1

Úvod

Čas potřebný ke studiu: 16 hodin a 30 minutTento čas reprezentuje dobu pro studium celého modulu.

Údaj je pochopitelně silně individuální záležitostí a závisí na sou-časných znalostech a schopnostech studujícího. Proto je vhodné jejbrát v úvahu pouze orientačně a po nastudování prvních kapitol siprovést vlastní revizi.

Cíle kapitolyCílem modulu je seznámit studujícího s širokou a moderní oblastí ob-jektově orientovaných programovacích jazyků (dále OOJ), které bylyzmíněny již v prvním modulu (IPP I) v rámci kapitoly Klasifikace ja-zyků. Ty modul studuje z hlediska nových přístupů k programovánía myšlení nejen při samotné implementaci objektových systémů, alei při jejich analýze a návrhu. Neopomíná samozřejmě základní vlast-nosti takovýchto jazyků spolu s naznačenými možnostmi využití, im-plementace i modelování.Po ukončení studia modulu:

• budete chápat základní paradigmata objektové orientace;

• budete schopni klasifikovat objektově orientované jazyky (OOJ)a jejich vlastnosti;

• budete schopni se na základě dosažených přehledových znalostírozhodovat o kvalitě a použitelnosti konkrétních OOJ pro řešeníkonkrétních problémů;

• budete mít pasivní znalosti formálních aparátů pro popis syn-taxe a sémantiky OOJ

5

6 KAPITOLA 1. ÚVOD

• budete mít přehledové znalosti o modelování grafickým jazykemUML, které tak můžete samostatně dále rozvíjet.

7

Obsah1.1 Koncepce modulu . . . . . . . . . . . . . . . 8

1.2 Potřebné vybavení . . . . . . . . . . . . . . . 9

8 KAPITOLA 1. ÚVOD

Průvodce studiemModul začíná popisem paradigmat objektové orientace spolu se zákla-dní klasifikací OOJ. Dále potom postupuje podle jednoho zvolenéhokritéria a předkládá vlastnosti OOJ z hlediska uživatelského i im-plementačního. Pozastavuje se nad možnými formalismy spojenýmis takovými jazyky, včetně způsobu popisu objektových modelů.Rozčlenění kapitol se pokoušelo udržet jejich vzájemnou relativněnízkou závislost. Proto je možné, pokud je vám nějaká oblast blízká,přejít vpřed na další oblast.V první kapitole se probírají základní principy objektové orientacea základní pojmy z této oblasti, které student uplatní při studiumlibovolného konkrétního OOJ. Následuje krátká kapitola o formálnímpopisu OOJ a přehledová kapitola o modelovacím jazyce UML. Modulje zakončen pokročilou kapitolou o vlastnostech objektově orientova-ných jazyků.Pro studium modulu je důležité být aktivním programátorem a nověnabyté znalosti si prakticky odzkoušet. Aktivní užití některého z ty-pických představitelů objektově orientovaných jazyků se tak stávájasnou výhodou jak při samotném studiu, tak při chápání širších sou-vislostí. Nestačí pochopit jen to, jak jazyk vypadá zvenčí (syntaxe asémantika), ale i co se skrývá za tím, že se chová tak, jak se chová.

Pro studium tohoto modulu je tedy nezbytné, aby měl studujícíNávaznost na předchozíznalosti základní znalosti ze strukturovaných a modulárních programovacích

jazyků a, jak již bylo zmíněno, byl aktivním programátorem alespoňv jednom vyšším, nejlépe objektovém programovacím jazyce. Pojmemaktivní programátor se zde chápe člověk, který si bude prakticky ově-řovat a zkoušet získané znalosti i úlohy napomáhající k pochopeníprobírané látky.

1.1 Koncepce modulu

Začíná se kapitolou nejobecnější, která je nutnou prerekvizitou prostudium každého objektově orientovaného jazyka nebo modelu. Ná-sleduje matematičtější kapitola, která má za úkol nastínit formálníaspekty práce s takovýmito jazyky, ale není zcela nezbytná pro pocho-pení zbývajícího textu. Další část se věnuje především modelování apopisu analýzy a návrhu aplikací pomocí objektové orientace a grafic-kého jazyka UML. Jedná se spíše o přehledovou kapitolu, která opakujea případně rozšiřuje znalosti o UML z předchozího studia. Pro tutooblast nebylo dostatek prostoru na vyčerpávající výklad, a to ani ne-muselo — z důvodu dostupnosti velkého množství kvalitní literatury

1.2. POTŘEBNÉ VYBAVENÍ 9

na toto téma i v českém jazyce. Poslední pasáže modulu se věnují ná-ročnějším vlastnostem OOJ a možnostem jejich implementace. Sicese nedovíte, jak přesně postupovat například při tvorbě překladačenebo celého prostředí nového OOJ, ale přesto se zde nalézají velmihodnotné informace pro pochopení některých klíčových vlastností aomezení OOJ.

Studium modulu vyžaduje sekvenční přístup především v rámcijednotlivých kapitol.

1.2 Potřebné vybaveníPro studium a úspěšné zvládnutí tohoto modulu není třeba žádné

speciální vybavení. Je však vhodné doplnit text osobní zkušenostís nějakým reprezentantem objektově orientovaných jazyků (napříkladSmalltalk, Java, C#, C++, příp. SELF). Potom je ovšem nutné mítpřístup k odpovídající výpočetní technice a ke zdrojům nabízejícímpřekladače či interprety daných jazyků, což je v současnosti typickyInternet.

Další zdrojeObjektově orientované programovací jazyky jsou jednotlivě předsta-vovány v řadě publikací.Zatímco u jazyků jako takových najdeme řadu i českých titulů (např.Eckel: Myslíme v jazyku C++, či Herout: Učebnice jazyka Java,nebo Bloch: Java efektivně), tak u obecnější teorie objektově orien-tovaných jazyků jsou tituly typicky anglické (např. Abadi, Cardelli:A Theory of Objects). Proto jsou v textu u klíčových termínů uvá-děny i odpovídající termíny anglické, které by měly usnadnit vy-hledání relevantních odkazů na Internetu (např. www.google.com,www.wikipedia.org), který je v tomto směru bohatou studnicí zna-lostí, jež mohou vhodně doplnit a rozšířit studovanou problematiku.Je však nutné být při akceptování poznatků z Internetu obezřetný,protože se často nejedná o recenzované nebo jinak editorsky schválenétexty, a ty mohou proto obsahovat i nepravdivé či nepřesné údaje.

10 KAPITOLA 1. ÚVOD

Kapitola 2

Principy objektověorientovaných jazyků

Tato kapitola obsahuje popis základních vlastností a problémů obje-ktově orientovaných jazyků (dále OOJ), které navíc již mají některévlastnosti modulárních jazyků.

Čas potřebný ke studiu: 3 hodiny 15 minut.

Cíle kapitolyHlavní cílem kapitoly je seznámit čtenáře s hlavními koncepty ob-jektově orientovaného paradigmatu a základními pojmy objektověorientovaných jazyků (OOJ), včetně jejich klasifikace. Předevšímv druhé části kapitoly bude přehledovým způsobem vysvětlena řadanejčastěji používaných pojmů a definic v kontextu objektově orien-tovaných jazyků.

Průvodce studiemPři studiu základních a později i pokročilých vlastností objektověorientovaných jazyků budou všechny pojmy vysvětleny za předpo-kladu použití čistě objektově orientovaného jazyka.Konkrétní OOJ se pravděpodobně bude od ideálního stavu odchy-lovat a lišit, takže při následném studiu konkrétního OOJ (např. zaasistence kvalitní odborné literatury) budete na tyto odlišnosti jistěupozorněni. Na některé nejznámější úskalí některých nejrozšířenějšíchOOJ krátce upozorníme již v tomto textu.

11

12 KAPITOLA 2. PRINCIPY OBJEKTOVĚ ORIENTOVANÝCH JAZYKŮ

Obsah2.1 Základní charakteristika . . . . . . . . . . . 13

2.1.1 Historie . . . . . . . . . . . . . . . . . . . . 14

2.1.2 Základní pojmy . . . . . . . . . . . . . . . . 14

2.1.3 Základní koncepty OOP . . . . . . . . . . . 15

2.1.4 Model výpočtu . . . . . . . . . . . . . . . . 18

2.1.5 Výhody a nevýhody OOP . . . . . . . . . . 19

2.2 Datové a řídící abstrakce . . . . . . . . . . . 20

2.2.1 Třídně orientované jazyky . . . . . . . . . . 20

2.2.2 Prototypově orientované jazyky . . . . . . . 30

2.3 Závěr . . . . . . . . . . . . . . . . . . . . . . . 34

2.4 Studijní literatura . . . . . . . . . . . . . . . 36

2.1. ZÁKLADNÍ CHARAKTERISTIKA 13

Výklad

2.1 Základní charakteristikaTato skupina jazyků rozšiřuje modulární jazyky o možnost spojit kon-krétní data i s operacemi, které je manipulují. Data stojí v centrupozornosti jak návrhářů jazyka, tak potom těch, kteří implementujíprogram.

Zevrubně řečeno, objektově orientované programování využívá připsaní programů také dekompozici do modulů. Tyto moduly ovšemtvoří zcela samostatné celky a objektově orientované paradigma pevněurčuje způsob práce a komunikace s těmito celky.

Definice 2.1.1 Objektově orientované programování (OOP) je způ- Definice!sob abstrakce, kdy algoritmus implementujeme pomocí množiny za-pouzdřených vzájemně komunikujících entit, z nichž každá má plnouvýpočetní mocnost celého počítače.

Alan Kay

Objektově orientovaný přístup k programování je založen na intui-tivní korespondenci mezi softwarovou simulací reálného systému a re-álným systémem samotným. Analogie je především mezi vytvářenímalgoritmického modelu skutečného systému ze softwarových kompo-nent a výstavbou mechanického modelu pomocí skutečných objektů.Podle této analogie i ony softwarové komponety nazýváme objekty.Objektově orientované programování pak zahrnuje analýzu, návrh aimplementaci aspektů, kde jsou reálné objekty nahrazeny těmi soft-warovými (virtuálními).

Definice 2.1.2 Objektově orientovaný systém (program, aplikace) se Definice!skládá z jednoho či více objektů, které spolu komunikují a interagujípři spolupráci na řešení daného problému.

Hlavní výhody objektové orientace bychom mohli shrnout do třínejpodstatnějších bodů:

• analogie mezi softwarovým modelem a reálným modelem,

• flexibilita takovýchto softwarových modelů,

• a jejich znovupoužitelnost.


2.1.1 Historie

V roce 1966 vytvořili O.-J. Dahl a K. Nygaard simulační jazykSIMULA, který je považován za první objektově orientovaný jazyk,který mimo jiné zavedl i pojem třída. O několik let později se v PaloAlto Research Center firmy Xerox podíleli dr. Alan Kay a Adele Gol-dbergová na vývoji prvního objektově orientovaného grafického sys-tému, který si kladl za cíl sloučit prostředky pro ovládání systému avývojové prostředí do jednoho jazyka, který byl nazván Smalltalk-72a postupem času se vyvinul do dnešní standardní podoby Smalltalku-80. Tento projekt se zabýval vytvořením osobního počítače s grafickýmuživatelským rozhraním. Světlo světa spatřily koncepty jako zásílánízpráv, dědičnost a grafické uživatelské rozhraní. V samotném jazyceSmalltalk je hodně stop po inspiraci prvním neimperativním jazykemLISP.

Idea objektově orientovaného programování se začala rychle rozrů-stat v 70. a počátkem 80. let, kdy Bjorn Stroustrup integroval objek-tově orientované paradigma do jazyka C, a dal tak vzniknout v roce1991 velmi populárnímu C++, který se stal prvním masově rozšíře-ným objektově orientovaným jazykem. Poté na začátku 90. let začalaskupina společnosti Sun pod vedením Jamese Goslinga vyvíjet zjed-nodušenou verzi C++, kterou nazvali . Původně se mělo jednat o pro-gramovací jazyk pro video-on-demand aplikace, ale nakonec se projektpřeorientoval na internetové aplikace. Celosvětového rozšíření se tentojazyk dočkal relativně brzy po uvedení na trh, hlavně díky obrovskéexpanzi Internetu a dobrému marketingu.

Pro vývoj v OOJ je také z pohledu softwarového inženýrství velmidůležitá racionalizace zápisu s využitím grafického jazyka UML, kterýbyl vypracováván od 90. let, především trojicí metodologů Grady Bo-och, Ivar Jacobson a Jim Rumbaugh, a hojně je využíván při objektověorientované analýze a návrhu dodnes (již verze 2.1).

2.1.2 Základní pojmy

Pojem objekt lze definovat hned několika způsoby a většinou záležíobjektna úhlu pohledu. Žádná z definic se však naštěstí nevylučuje, a taknic nebrání, abychom si jich uvedli více. Nejobecnější programátorskýpohled definuje objekt jako jednoznačně identifikovatelný reálný ob-jekt (se sémantikou z obecné češtiny) nebo abstrakci (to v případě,že reálný objekt popisujeme nějakým abstraktním modelem), kterázahrnuje data a jejich chování (operace nad těmito daty). V případějazyka založeného na třídách lze pojem objekt ještě přesněji popsatjako instanci třídy obsahující data a operace. Tento populárnější po-


pis lze ještě zobecnit a říci, že objekt je entita, která rozumí zasláníněkterých zpráv a ve své vnitřní struktuře umožňuje zapouzdřit dalšíobjekty (může se skládat z dalších objektů).

Definice 2.1.3 Objekt je entita zapouzdřující stavové informace Definice!(data reprezentovaná dalšími objekty) a poskytující sadu operací nadtímto objektem nebo jeho částmi.

Vnitřním buňkám obsahujícím tyto zapouzdřené další objekty(nebo reference na ně) budeme říkat instanční proměnné nebo takéatributy1 a budou tvořit pojmenované datové části objektu. Objektyvzájemně interagují a komunikují pomocí tzv. mechanismu zasílánízpráv. Zpráva je komunikační jednotka mezi dvěma libovolnými ob- zprávajekty. Kromě svého jména může obsahovat i dodatečné informace v po-době parametrů (argumentů), které slouží pro podrobnější specifikacizprávy a tedy i upřesnění informace předávané mezi těmito objekty.Zaslaná zpráva má jak svého odesilatele, tak příjemce (objekt, kterémuje zpráva záslána). Její sémantika je pak taková, že příjemce (adresát)na obdrženou zprávu od odesilatele reaguje vyhledáním patřičné im-plementace reakce na tuto zprávu, což bývá nejčastěji odpovídajícízapouzdřená funkce, kterou budeme nazývat metoda. Metody imple-mentují veškeré chování objektů, nebo chcete-li reakce na obdrženézprávy, a mívají spolu se zprávami také shodné jméno i seznam pa-rametrů. Množina všech zpráv, kterým objekt rozumí, tj. je schopennalézt implementaci odpovídající metody, se nazývá protokol objektu.Někdy se též lze setkat s pojmen rozhraní objektu.

2.1.3 Základní koncepty OOP

Objektově orientované programování slučuje nové programovací kon-cepty a vylepšuje staré, aby tak dosáhlo přiblížení popisu reálnéhosvěta k lidskému způsobu uvažování. Tyto koncepty bývají často ozna-čovány za stavební kameny objektově orientovaného paradigmatu.

• Objekty – spojují data a funkcionalitu společně do jednotekzvaných objekty, ze kterých se potom skladá výsledný objek-tově orientovaný program na rozdíl od strukturovaného slože-ného z procedur a funkcí. Objekty jsou tedy základní jednot-kou modularity i struktury v objektově orientovaném programu,

1Pojem atribut budeme upřednosťnovat v obecnějším popise. V případě in-stanční proměnné zdůrazňujeme implementační přístup, tj. reference na obsaho-vaný objekt.


která umožňuje problém intuitivně rozdělit na přímo realitě ko-respondující podčásti a díky jejich vzájemné komunikaci i tentoproblém řešit.

• Abstrakce – neboli schopnost programu ignoro-vat/zjednodušit/zanedbat některé aspekty informací čivlastnosti objektů, se kterými program pracuje. Abstrakceje pohled na vybraný problém reálného světa a jeho počítačovéřešení. Při vytváření takovéto abstrakce je vhodné mít možnostskrývat detaily do jakési černé skříňky (angl. black box), kteráje pro okolí definovaná pouze svým rozhraním, přes kterékomunikuje s okolím, a nikoli vnitřními detaily implementace,která může být podstatným zjednodušením reálného světa. Přikonstrukci černé skříňky je dobré mít na paměti varianty ainvarianty řešeného problému2.

Důležitým rozhodnutím je potom míra abstrakce, tedy jak hodněje vzdálená funkčnost černé skříňky od reality, respektive jak de-tailně potřebujeme realitu pomocí této abstrakce modelovat. Zdeje hlavním limitujícím faktorem složitost a náročnost implemen-tace perfektní černé skříňky, která by byla jednoduše použitelná,určená pouze svou funkcionalitou velmi blízkou reálnému chováníabstrahovaného objektu či problému.

• Zapouzdření – zajišťuje již na úrovni definice sémantiky ja-zyka, že uživatel nemůže měnit interní stav objektů libovol-ným (tedy i neočekávaným) způsobem, ale musí k tomu vyu-žívat poskytované rozhraní (operace nad objektem). Každý ob-jekt tedy nabízí protokol, který určuje, jak s ním mohou ostatníobjekty interagovat (komunikovat). Ostatní objekty se tedy přikomunikaci s tímto objektem spolehají pouze na jeho externí(poskytované) rozhraní a skutečná implementace zůstává doko-nale skryta. Právě tento koncept zásadně zjednodušuje vývojnových vlastností a vylepšování stávající implementace našehoprogramu, protože nám stačí zachovat pouze zpětnou kompati-bilitu rozhraní objektů a nikoli skrytých implementací.3 Klíčovouroli hraje tato vlastnost také pro umožnění znovupoužitelnostiobecnějších objektů v různých projektech.

2Invariant je taková část programu, že se hodnoty proměnných ani chovánítéto části programu nemění při opakovaném provádění (průchodu) kódu této částiprogramu. Zcela opačně je popsán variant, což je část programu, která hodnotyproměnných nebo svoje chování alespoň v některých průchodech mění.

3Některé OOJ umožňují přísné zapouzdření instančních proměnných porušovatpomocí tzv. modifikátorů viditelnosti (viz sekce 5.3.3 na straně 68).


• Polymorfismus – neboli mnohotvárnost využívá mechanismuszasílání zpráv. Namísto běžného volání podprogramů (procedura funkcí) ve strukturovaném programování se v OOJ využívámechanismu zasílání zpráv. Konkrétní použitá metoda reagu-jící na zaslání zprávy závisí na konkrétním objektu, jemuž jetato zpráva zaslána. Například, pokud máme objekt orel a po-šleme mu zprávu rychle_se_přemísti, tak implementace rea-gující metody bude pravděpodobně obsahovat příkazy pro roz-tažení křídel a vzlétnutí. Pokud ale budeme mít objekt gepard,tak implementace metody volané při obdržení téže zprávy budeobsahovat například příkaz pro rozběhnutí se. Obě reakce napříjem stejné zprávy byly uzpůsobeny potřebám konkrétního ob-jektu, který zprávu obdržel, a tudíž byly plně v jeho vlastní režii.Takto získáme polymorfismus, kdy ta samá proměnná programumůže během jeho běhu obsahovat či odkazovat různé objekty,a tak může zaslání stejné zprávy objektu ve stejné proměnnépři provádění stejné části kódu vyvolat během různých kontextů(časových bodů, obsahů proměnných či instančních proměnných,hodnot parametrů) rozdílné reakce (invokovat různé metody).

• Dědičnost – je způsob, jak implementovat sdílené chování. Novéobjekty tak mohou sdílet a rozšiřovat chování těch již existujícíchbez nutnosti vše znovu reimplementovat4. Dědičnost se v praxivyužívá ke dvěma účelům: (1) k indikaci, že nové chování spe-cializuje jiné již existující chování5 a (2) pro sdílení kódu (im-plementace metod). Tato vlastnost je tedy velmi důležitá proudržovatelnost a rozšiřitelnost (róbustnost) objektově orientova-ných systémů.

První tři koncepty lze při dobré vůli a snaze programátora využí-vat již v modulárním způsobu programování, ale až OOP nás nutí tytozásady přísněji dodržovat. Některé hybridní objektově orientované ja-zyky jako C++ nám umožňují částečné obcházení některých těchtokonceptů (např. veřejný modifikátor videlnosti u instančních proměn-ných tříd; existence entit, které nejsou objekty nebo klasická voláníprocedur a funkcí obcházejících mechanismus zasílání zpráv).

Důležitou operací prováděnou nad objekty je identita. Identita po- identita vs shodarovnává, zda jsou objekty totožné, zda se jedná o tentýž objekt. Shod-nost dvou objektů je operace, která provádí porovnání objektů podlejejich obsahu. Za shodné pak mohou být označeny i neidentické ob-

4Jazyky založené na objektech pracují místo dědičnosti s pojmem delegace.5Ve staticky typovaných jazycích hraje vztah dědičnosti významnou roli při

typové kontrole.


jekty. Matematicky řečeno, identita dvou objektů implikuje shodnostobjektů, ale ne naopak.

Příklad 2.1.1 Ukázka pojmu shoda a identita pomocí tří proměnnýchobsahujících dva objekty (objekt vytvoříme pomocí literálu | seznamatributů s hodnotami |).

pavel := | vek = 10, vyska = 135 |tomasuvSyn := martin := | vek = 10, vyska = 135 |

Objekt v proměnné pavel je shodný s objektem v proměnnémartin i s objektem v proměnné tomasuvSyn, protože mají stejnéhodnoty všech atributů.Objekt v proměnné pavel není identický s objektem v proměnnýchmartin respektive tomasuvSyn, protože se nejedná o tu samou částpaměti, tj. změna atributu v objektu pavel nemá stejný efekt na ob-jekt martin.Ale objekt v proměnné martin je identický s objektem v proměnnétomasuvSyn.

2.1.4 Model výpočtu

Model výpočtu v čistě OOJ obsahuje vždy alespoň dvě následujícízákladní sémantické konstrukce.

První konstrukcí je pojmenování objektu neboli přiřazení objektupřiřazenído proměnné. Místo samotného objektu se může pracovat s referencí6nebo ukazatelem na daný objekt.

Druhá konstrukce je zaslání zprávy objektu. Samotná zprávazaslání zprávykromě svého identifikátoru (jména) může obsahovat také parametry(další objekty upřesňující význam zprávy). Způsob reakce objektu napřijatou zprávu záleží již na něm samotném, což je důsledek konceptuzapouzdření a polymorfismu. U objektů jsou reakce na zprávy nejčas-těji implementovány pomocí stejně pojmenovaných metod. Při obdr-žení zprávy příjemcem mohou nastat tři různé situace:

1) Objekt ve své implementaci při reagování na zprávu nalezne azavolá příslušnou metodu.

2) Objekt sice hledanou metodu přímo neobsahuje, ale obsahujeji jiný objekt v rodičovském vztahu s tímto objektem. Přesný

6Např. v jazyce C++ je reference speciální typ ukazatele, který ale nepovolujeobsahovat nedefinovanou hodnotu neboli neukazovat nikam.


způsob, jakým se hledají žádané metody v objektu samotném av objektech k němu vztažených, probíhá v závislosti na progra-movacím jazyce a je závislý na způsobu implementace konceptudědičnosti a tzv. směrování zpráv.

3) Objekt implementaci odpovídající metody neobsahuje a ani ne-byla nalezena v objektech předků, jak to popisuje předchozí pří-pad. Pak nastává výjimka (chyba), že přijaté zprávě nebylo po-rozuměno, neboli že k ní neexistuje odpovídající metoda. U dy-namicky typovaných (např. Smalltalk) a netypovaných jazykůje tento případ poměrně častým projevem nedokončené imple-mentace chování daného objektu nebo špatného použití danéhoobjektu. Staticky typované jazyky (např. C++, C# a Java) na-opak dokáží tuto situaci většinou rozpoznat již při překladu aupozornit na ni chybovým hlášením.

Po vykonání metody, jež reagovala na zprávu, se řízení běhu objek-tového programu zpravidla vrací spolu s návratovou hodnotou (pokudnějaká je) do objektu odesilatele, kde se pokračuje ve výpočtu (v me-todě, která zprávu odeslala). Takže z hlediska zpracování se metodychovají analogicky jako obyčejné funkce.

2.1.5 Výhody a nevýhody OOP

Následuje několikabodové shrnutí výhod a nevýhody OOP:

+ vyšší míra abstrakce

+ přirozenější práce se zapouzdřením a moduly (softwarový objektje analogií/abstrakcí reálného objektu, a lze jej považovat zajakýsi samostatný modul)

+ jednodušší dekompozice problémů (rozdělení mezi abstrakci azapouzdření)

+ udržovatelnost a rozšiřitelnost (róbustnost; změny mají vzhle-dem k objektům i třídám lokální charakter a vždy je jasně vy-mezeno, kde se všude mohou změny promítnout; eliminace po-stranních efektů)

+ znovupoužitelnost (nejen koncept dědičnosti, ale i možnost vyu-žívat množiny cizích objektů při znalosti jejich rozhraní respek-tive protokolu pro komunikaci s nimi)

- v některých oblastech neexistuje analogie s reálnými objekty apak je obtížné určit a definovat intuitivně ty softwarové


- složitější sémantika než u modulárních a strukturovaných jazykůvyžaduje více času na naučení

- nemožnost porušovat koncepci zapouzdření (v některých jazy-cích jako Java a C++ je to obcházeno pomocí modifikátorů vi-ditelnosti)

- výsledný generovaný kód je pomalejší kvůli využívání dodateč-ných kontrol či odlišných modelů výpočtu než jsou vlastní vonNeumannově architektuře počítače (virtuální objektová paměť avirtuální stroj, viz kapitola 5.4.2)

- režie na uložení objektů v paměti (např. odkaz na třídu objektu)

Pojmy k zapamatováníObjekt, zpráva, metoda, protokol, rozhraní, abstrakce, zapouzdření,polymorfismus, dědičnost

2.2 Datové a řídící abstrakce

Nyní jsme si popsali objekt a jeho základní části. V případě, že bu-deme s objekty programovat, tak velice často budeme potřebovat, abynějaká množina objektů rozuměla stejným zprávám, a nebo dokonceměla i stejnou reakci na přijaté zprávy (metody). První možnost, kte-rou máme k dispozici, je mít v každém objektu znovu přítomné tysamé metody, a případně i ten samý kód. To by ovšem značně znepří-jemňovalo samotné programování, udržování programu a v neposlednířadě mělo obrovské paměťové nároky. Řešení, které využívá většinaOOJ hlavního proudu (angl. mainstream) zavádí pojmy — třída adědičnost. Obecně se těmto jazykům říká jazyky založené na třídách(angl. class-based), čili třídní jazyky. K tomuto existuje i alternativníbeztřídní řešení, které popíšeme až na konci kapitoly a používá pojmyjako prototyp, rys a delegace. Tento přístup bývá využíván v jazycíchzaložených na objektech (angl. object-based), neboli prototypovacíchjazycích.

2.2.1 Třídně orientované jazyky

Pokud máme v systému více objektů, které obsahují sice jiné hodnoty,ale stejné metody a shodnou vnitřní strukturu (množinu instančníchproměnných), tak je výhodné pro takovéto objekty vytvořit speciálníobjekt, který nazveme třída a který slouží jako společný popis jejichvlastností (nikoli přímo hodnot atributů).

2.2. DATOVÉ A ŘÍDÍCÍ ABSTRAKCE 21

method1

method2

instVar1(metadata)

instVar2(metadata)

classVar1

classVar2

Class ADescription: template for

instances (objects createdfrom this class) instVar2 = value2

instVar1 = value1

Instance of class A

instVar2 = value4

instVar1 = value3

Instance of class A

method1()

create

create

classMethod1

Obrázek 2.1: Třída je šablona pro tvorbu instancí a případně i zajišťujereakce na zprávy zaslané těmto instancím.

Definice 2.2.1 Třída je šablona (otisk), podle níž mohou být vytvá- Definice!řeny objekty (instance této třídy). Třída se také stará o správu pro-tokolu objektu, směrování zpráv a obsahuje implementace některýchmetod.

Na třídu lze také nahlížet jako na metadata o objektu, která jsouzobecněním a zapouzdřením pojmu abstraktního datového typu zave-deného v předchozích kapitolách o modulárním programování.

Matematicky lze na projem třída nahlížet jako na podmnožinumnožiny všech objektů takovou, že její prvky mají něco společného.V našem případě mají společný protokol a vnitřní strukturu (případnědalší společná metadata).

Instanciace objektů

Proces samotného vytváření objektu pomocí předpisu daného kon-krétní třídou nazýváme instanciace, nebo též vytvoření instance třídy.Instance třídy je objekt, který obsahuje naplněny instanční proměnnéa odkaz na třídu, ze které vznikl (svým způsobem se jedná o typo-vou informaci, která je často nutná nejen při překladu, ale i za běhuprogramu).

Bezprostředně po vytvoření objektu (vyhrazení prostoru v pamětia naplnění odkazu na třídu původu do této paměťové struktury) do-stáváme prázdný objekt, jehož datové položky (instanční proměnné)musejí být teprve naplněny, neboli inicializovány. K tomu je obvyklev dané třídě vyčleněna jedna nebo více metod a takovouto metoduoznačujeme jako konstruktor. Strategie volání konstruktorů se jazyk


od jazyka liší a v některých případech je poměrně komplikovaná (např.pořadí volání konstruktorů v jazycích s vícenásobnou dědičností jakoje C++). V mnoha jazycích se dodržuje zvyklost, že jméno konstruk-toru odpovídá jménu třídy (např. Java, C++, C#), které patří, nebomá nějaké předem stanovené neměnné jméno pro všechny třídy (např.PHP5, Python).7

Pro operaci vytvoření objektu se používá klíčové slovo8 new, kteréobsahuje jako parametr jméno třídy, která pro něj bude sloužit jakokonstrukční šablona, a případný seznam hodnot parametrů, které jsoupředány konstruktoru (pokud jej daný OOJ automaticky volá).

K tématu vytváření objektů patří i poznámka o dvou přístupechk vytváření kopií objektů (ať již na úrovni třídních nebo prototypova-kopírování objektůcích jazyků, kde hovoříme o tzv. klonování):

• hluboká kopie (angl. deep copy) — Kromě objektu jako tako-vého (soubor atributů) jsou kopírovány i objekty, které ony in-stanční proměnné referencují. V případě provádění hluboké kopieje často potřeba si i určit, do jaké hloubky (úrovně) se kopírováníprovádí, jinak by mohlo dojít ke kopírování velké části objektovépaměti.

• mělká kopie (angl. shallow copy) — Jednoduše řečeno se jednáo hlubokou kopii do hloubky nula. Je tedy vytvořen nový objekt,ale všechny instanční proměnné obsahují odkazy na totožné ob-jekty jako kopírovaná předloha.

Manipulace s objekty v kódu a v paměti

Pokud nově vytvořený objekt přiřadíme do proměnné, lze rozlišovatdva případy:

a) Jazyky jako Oberon nebo C++ rozlišují, zda je objekt alo-kován na zásobníku či haldě a rozlišují tak mezi samotnýdatovým záznamem objektu (blok paměti obsahující hod-noty datových členů objektu) a pouhou referencí na objekt.Tento přístup je sice komplikovanější a vyžaduje hlubší pro-gramátorův zájem, ale na druhou stranu pak umožňuje pro-vádět efektivnější optimalizace, a to již v době překladu.

7Smalltalk umožňuje implementaci vlastní třídní metody vlastního názvu atudíž lze zvolit i jméno konstruktoru; standardně initialize.

8nebo třídní zpráva (např. v Pythonu jde o třídní zprávu pojmenovanou jakosamotná třída spolu s kulatými závorkami na případné parametry následně předá-vané konstruktoru)


b) Naopak jazyky jako je Simula, Smalltalk nebo Modula-3před programátorem tento rozdíl skrývají a pracují s ob-jekty pouze přes reference. Tímto mechanismem lze ušetřitpaměť nejen při provádění příkazu přiřazení, ale také připředávání parametrů (tzv. implicitní předávání odkazem).

Samotný objekt v paměti obsahuje pouze hodnoty instančních pro-měnných a metainformaci určující, z jaké vznikl třídy, která již za-jišťuje poskytnutí dalších důležitých informací o objektu (metainfor-mace), jako např. protokol objektu nebo umístění kódu metod.

Rušení objektů v paměti

V dnešní době se používají dva způsoby rušení instancí:

1. Automaticky — Automatické rušení je většinou možné pouzev případě běhu objektového prostředí ve virtuálním stroji a pro-vádí jej nástroj zvaný garbage collector, který jednou za čas vy-hledá objekty, na které již neexistuje žádný odkaz a ty zruší.Tímto postupem se likvidují i shluky objektů. Shluk objektů jemnožina objektů odkazovaných sice mezi sebou, ale žádným ob-jektem mimo shluk. Těsně před samotným zrušením umožnujevětšina jazyků volat specializovanou metodu pro úklid a uvolněníalokovaných zdrojů mimo objekt (např. připojení k databázi čiotevřené soubory), tzv. finalizace. Záruka volání finalizační me- finalizacetody při destrukci objektu se liší jazyk od jazyka.

2. Manuálně — V případě, že nemáme k dispozici garbage colle-ctor (většinou u jazyků kompilovaných přímo do nativního kóduprocesoru) nebo jej máme možnost nepoužít, tak je potřeba seo rušení objektů starat manuálně (tedy na úrovni zdrojovéhokódu). Pro likvidaci objektů bývá vyčleněna speciální metoda,tzv. destruktor, kterou když programátor zavolá, tak na jejím destruktorkonci je objekt uvolněn z paměti. Kvůli dědičnosti musí tytojazyky specifikovat pořadí volání destruktorů (analogicky jakou konstruktorů). Další specialitou je tzv. virtuální destruktor,který má analogickou funkci jako virtuální metody (viz popispolymorfismu v sekci 2.2.1 na straně 29). V případě špatnéhouvolňování paměti, kterou má plně na zodpovědnost programá-tor, vznikají tzv. úbytky paměti (angl. memory leaks).

Dědičnost a hierarchie tříd

Z matematického pohledu dědičnost zavádí relaci „třída B dědí odtřídy A“. Tato reflexivní, tranzitivní a antisymetrická relace tvoří čás-


tečné uspořádání na množině tříd a vyúsťuje v možnost uspořádánítříd, v případě jednoduché dědičnosti, do stromové hierarchie tříd.Pak třídě A říkáme rodič třídy B a naopak B je potomek A. Koře-nem takovéhoto hierarchického stromu tříd je třída, která je předkemvšech ostatních tříd. V listech jsou naopak třídy, které již nemají žádnépotomky.

Účely dědičnosti

1. znovupoužití definované třídy pro specifičtější verzi třídy (typu)

2. zajištění zpětné kompatibility z pohledu rozhraní instancí zdě-děných tříd

Klasifikace dědičnostiDvě základní kritéria klasifikace dědičnosti tříd jsou (A) „Kolik

rodičů může mít potomek?“ a (B) „Co se dědí?“:

(A1) Jednoduchá dědičnost říká, že každý potomek má nejvýše jed-noho přímého předka (rodiče). Např. jazyk Java, Smalltalk, C#.

(A2) Vícenásobná dědičnost je případ, kdy může třída dědit od vícepřímých předků (více jak jednoho). Do hry však přichází pro-blémy s konflikty a duplikací jmen členů různých předků apod.Nejčastější řešení těchto problémů je zakázání výskytu konflikt-ních jmen členů nadtříd, případně vyžadování uvádění kvalifika-ce předka, ze kterého konfliktní metody invokovat9. Další výzvouv jazycích s vícenásobnou dědičností je vytvoření optimálního anejpoužitelnějšího algoritmu pro vyhledávání metod, které majíreagovat na zaslanou zprávu, kdy je nutno procházet oriento-vaný graf namísto jednoduchého stromu, jak je tomu v případějednoduché dědičnosti.

(B1) Dědičnost neboli dědičnost implementace – kromě atributů jsoudo dědičnosti zahrnuty celé metody včetně jejich implemen-tace. Zde právě v případě vícenásobné dědičnosti vzniká probléms různými implementacemi dvou stejných metod nebo s různýmidefinicemi dvou stejně pojmenovaných instančních proměnných.

(B1) Dědičnost rozhraní – ze snahy o využívání vícenásobné dědič-nosti, ale odstranění zmíněných problémů s konfliktními jmény,

9Přesněji řečeno je třeba uvádět předka, ve kterém má začít hledání reakce nazprávu, která má v aktuální třídě více zděděných reakcí (konfliktních metod).


vzniká přístup dědění pouze na úrovni rozšiřování protokolu ob-jektu. V praxi se jedná o předpis nebo seznam metod, které jenutno v potomkovi implementovat10 a tudíž splňuje druhý účeldědičnosti – dohodu o rozhraní.11

Příklad 2.2.1 Ukázka tranzitivity dědičnostiMějme neprázdnou sekvenci tříd C1, . . . , Cn, kde Ci+1 přímo dědí

od Ci pro všechna i ∈ {1, . . . , n−1}. Díky tranzitivitě dědičnosti tedyplatí, že i třída Cn dědí od C1. Dále platí, že třída Cn je tzv. podtyptřídy C1

12.

V čistě objektově orientovaných třídních jazycích jsou všechny en-tity objektem a každý objekt má svou třídu13. Z tohoto jednoduchéhokonceptu plyne i to, že i třídy mají své třídy, které označujeme jakometatřídy. Většina třídních jazyků na tomto místě třídní hierarchie(kořenový uzel) již umožňuje vytvořit smyčku (viz příklad 2.2.2), takžetřídou k metatřídě již většinou bývá samotná metatřída.

Příklad 2.2.2 Příklad na třídě Time jazyka Smalltalk, které zasílámezprávu class pro zjištění třídy, případně ještě zprávu name pro získánípřesného názvu třídy (řetězec je v apostrofech). Podstatné jsou pře-devším poslední tři řádky kódu, které demonstrují cyklus v hierarchiidědičnosti.

time := Time now. // zpráva vyvolá: třídní metodu nowtime class = Time. // instanční metodu classTime class name = ’Time class’. // třídní metodu class a nameTime class class = Metaclass.Metaclass class name = ’Metaclass class’.Metaclass class class = Metaclass.

Libovolný objekt má tedy instanční proměnné a třídu, která zajiš-ťuje operace nad tímto objektem. V případě, že objekt není třídou14,mluvíme o instančních proměnných a metodách. Pokud je objekt tří-dou, mluvíme o třídních proměnných a třídních metodách. Instančnímetody jsou implementací reakcí na zprávy, které obdržel objekt, ajsou uloženy ve třídě tohoto objektu. Instanční proměnné jsou součástípřímo daného objektu. Třídní metody jsou reakce na zprávy zasláné

10Dokud nemá potomek implementovány všechny požadované reakce na zprávy,nelze vytvářet jeho instance (viz obrázek 4.2 na straně 52).

11V praxi nemá smysl pracovat s jednoduchou dědičnosti rozhraní, ale čistěteoreticky je i tato kombinace možná.

12Formální zápis vztahu podtyp je zatím nejednotný, např.: Cn > C1 vyjadřující,že Cn je specifičtější než C1, tj. obsahuje více detailů; na druhou stranu zápisCn < C1 je odvozen od toho, že objekty podtypu Cn tvoří vždy podmnožinu(většinou vlastní) množiny instancí typu C1.

13Třída je také objekt.14Každý objekt je instancí třídy.


třídám (např. now z příkladu 2.2.2). Třídní proměnné jsou uloženy vetřídách.Třídy jsou unikátně pojmenované instance metatříd.

V hybridně objektových jazycích zpravidla nebývají metatřídy z ja-zyka přístupné. Definice třídních proměnných a třídních metod jev tom případě zapisována přímo do definice třídy (nikoli metatřídy) aoznačena předepsaným klíčovým slovem (nejčastěji static). Proto sepotom třídním proměnných a třídním metodám říká statické.statické proměnné a

metodyTypy, podtypy, nadtypy

Hovoříme-li o třídě jako o typu (podobně jako abstraktní datový typmá i třída operace a vnitřní uložení dat), tak v případě předka tétotřídy hovoříme o nadtypu (angl. superclass) a u potomka o podtypu(angl. subclass). Tento vztah však obecně v druhém směru neplatí,jak bude demonstrováno v této sekci.

Příklad 2.2.3 Jeden z motivačních příkladů pro zavedení dědičnostive staticky typovaných jazycích. Mějme metodu (případně funkci) m,která jako parametr vyžaduje objekt třídy A. Pak jako parametr lzemetodě m zadat:

1. objekt stejného typu (např. instanci třídy A);

2. objekt třídy odvozené od třídy A (např. pomocí dědičnosti).

Jednou z motivací pro zavedení dědičnosti ve staticky typovanýchjazycích je umožnění zástupnosti typů, které jsou odvozeny pomocídědičnosti od patřičných tříd (potažmo typů).

Je-li tedy instance třídy nebo z ní zděděné třídy vyžadována namístě parametru metody (příp. funkce), tak mluvíme o vyžadovanédědičnosti (angl. required inheritance), kdy dědičný vztah zajišťujevyžadovaná dědičnostexistenci potřebného protokolu (nebo jeho nadmnožiny; např. existen-ce patřičných atributů nebo virtuálních metod). Vyžadovaná dědičnostje zpravidla potřebná u staticky typovaných jazyků jako Java, C++nebo Object Pascal z prostředí Borland Delphi.

Pokud potřebujeme více volnosti s dosazování za parametry me-skutečný podtyptod, tak musíme využít jiný způsob zajištění existence metod (pří-padně i atributů). Nejpřímočařejší je kontrola existence požadovanýchmetod (příp. atributů) v konkrétním dosazovaném typu, což budemenazývat kontrola skutečného podtypu (angl. real subtype). Podobnýmzpůsobem je prováděna kontrola například v modulárním jazyce C přitestování kompatibility struktur (heterogenní strukturovaný typ) bě-hem kompilace. Tato kontrola je obecnější než vyžadovaná dědičnost,která může být dědičností v některých případech omezena.


Vyžadovaná dědičnost Výsledek Skutečné podtypy Výsledek

call q(a); OK call q(a) OKcall q(b); chyba call q(b) OKcall q(c); OK call q(c) OKcall p(b); chyba call p(b) chybacall p(c); OK call p(c) OK

Tabulka 2.1: Rozdíl mezi vyžadovanou dědičností a kontrolou skutečnéhotypu (sloupec Výsledek zachycuje výstup kontroly)

Příklad 2.2.4 Rozdíl mezi vyžadovanou dědičností a kontrolou sku-tečného typu (podtypu). Mějme deklarovány následující tři třídy A, B,C, takto:

class A isint d1;float d2;float f(int);

endOfClass

class B isint d1;float d2;float f(int);int g(float);

endOfClass

class C inheritedfrom A is

int d3;float f(int);int g(float);

endOfClass

Nyní uvažujme použití objektů těchto tříd jako parametrů násle-dujích dvou funkcí15:

int q(class A);int p(class C);

Tabulka 2.1 potom demonstruje rozdílné chování obou druhů kon-trol parametrů.

Nyní vidíme, že hlavní rozdíl spočívá v kontrole skutečné přítom-nosti implementace potřebného protokolu (metod, atributů) (tzv. sku-tečný typ) oproti kontrole jména typu v případě vyžadované dědič-nosti.

Z toho plyne, že nelze za všech okolností a ve všech OOJ zcela bez-myšlenkovitě zaměňovat pojmy třída a typ (resp. podtřída/nadtřídaa podtyp/nadtyp).

15Někdy je místo metod vhodnější příklady vlastností demonstrovat na funkcích,přestože jsou přítomné pouze v hybridně OO jazycích.


V třídních jazycích existují dva přístupy k typům:

1) Přístup čistě objektový (např. Smalltalk): Vše je objekt (prav-divostní, číselná hodnota i třída atd.) a existuje třída, nebo pří-padně objekt, od kterého jsou všechny ostatní odvozeny.

2) Přístup hybridně objektový (podobný strukturovaným jazy-kům): Máme k dispozici sadu základních, neboli primitivníchtypů (pravdivostní hodnota, číslo, znak, řetězec), které lze pří-primitivní typypadně skládat do homogenních nebo heterogenních struktur.Třída je potom případ heterogenní struktury, která může ob-sahovat kromě atributů i metody (funkce uvnitř této struktury).Při tomto přístupu rozlišujeme dva podpřípady:

a) Existuje kořenová třída, která je předkem každé existu-jící nebo nové třídy (např. třída Object v Javě a C#, TObjectv Object Pascalu, resp. Delphi)

b) Jazyky, které nemají v hierarchii dědičnosti žádnou koře-novou třídu (např. C++).

Z praktického hlediska je vhodné optimalizovat přístup k primi-tivním datovým typům (číslo, řetězec) i v jazycích čistě objektových,ale vždy takovým způsobem, aby to nemělo žádný vliv na objektovéchování těchto elementárních objektů.

Staticky typovaný jazyk určuje množinu operací, které objekt pod-staticky a dynamickytypovaný jazyk poruje, již v době překladu programu. V případě, že se zjistí, že

po objektu je požadována nepodporovaná operace, neproběhne pře-klad úspěšně. Dynamicky typovaný jazyk pak tuto kontrolu provádíaž v době běhu programu. V případě, že objekt požadovanou ope-raci nepodporuje, je proveden pokus o konverzi objektu na jiný typ,a případně vygenerována chyba (slabě typované jazyky) nebo je naslabě a silně typované

jazyky tuto skutečnost upozorněn přímo volaný objekt (silně typované ja-zyky). Poznamenejme, že definice slabě a silně typovaných jazyků sedost často v různých pramenech liší a není jednotná. Upřesnění těchtodefinic obsahuje kapitola 5.2.

Po zavedení pojmu třída lze na dědění nahlížet i jako na vytvářenípodtypů a nadtypů. Vytváříme tak stromovou hierarchii tříd (typů),jež mohou vyčleňovat společné vlastnosti do nadtypů a specializovatsvé vlastnosti do podtypů.

Práce s metodami

Redefinice metod (angl. method overriding) je možnost jazyka defino-redefinice metodyvat pro metodu podtřídy novou, specifičtější implementaci, než je obsa-žena v její nadtřídě. Obě metody přitom mají stejnou signaturu (jméno


metody, seznam formálních parametrů, návratový typ) jak v nadtřídě,tak v podtřídě. Implementace redefinované metody tedy nahradí im-plementaci, která se dědí z předka.

Redefinice metod je důležitý mechanismus OOJ, který obohacujemožnosti polymorfismu (viz sekce 2.2.1) a dědičnosti.

Poznamenejme, že některé OOJ na druhou stranu umožňují rede-finici metody pomocí klíčového slova zakázat.

V každém OOJ je, ať už implicitním nebo explicitním způsobem,označován objekt příjemce zprávy. Toto pojmenování slouží k referen-cování příjemce v kontextu právě vykonávané metody (včetně kon-struktoru nebo destruktoru). Nejčastěji se pro toto označení využívápseudoproměnná označená klíčovým slovem this nebo self. Impli-citní předávání příjemce zprávy metodě se většinou realizuje nultýmskrytým parametrem této metody. Je dobré si také uvědomit, že pří-jemcem zprávy nemusí být vždy instance třídy, která metodu definuje,ale i jejího libovolného potomka.

V případě, že redefinujeme metodu a chceme využít kódu již de-finované metody (tj. pouze obalit již existující stejně pojmenovanoumetodu novým kódem), tak potřebujeme mechanismus, jak se odká-žeme na metody předka (případně předků). V jazycích s jednoduchoudědičností se daný požadavek řeší přidáním nového klíčového slova(např. base nebo super), které podobně jako v předchozím odstavcireprezentuje pseudoproměnnou obsahující náš objekt přetypovaný ta-kovým způsobem, aby se tvářil jako instance rodičovské třídy. Při více-násobné dědičnosti je situace komplikovanější a pro odkaz na metodyv předcích, které již byly redefinovány, se používá specifikace konkrétnítřídy (např. A::puvodniMetoda() v C++), tzv. kvalifikace jména.

Polymorfismus - časná a pozdní vazba

Polymorfismus umožňuje na místě jednoho objektu používat jiný bez polymorfismusnutnosti jakýchkoliv zásahů do programu. Bez jeho existence bychommuseli programovat zvláštní kód pro každý možný typ objektu, sekterým hodláme komunikovat. To přirozeně není vzhledem k návrhuprogramu vůbec vhodné.

V praxi potřebujeme pracovat s objekty v obecné rovině, tzn. žejim zasíláme zprávy a ty na ně reagují podle vlastní potřeby, což od-povídá jisté míře autonomnosti objektů. Podle zásady zapouzdření jejen na vůli objektu samotného, jak se zprávou naloží. Při komunikacis objektem nás zajímá pouze jeho veřejné rozhraní. Objekty, které totorozhraní mají podobné a pokrývají všechny námi požadované operace,můžeme považovat za zaměnitelné. Z toho je patrné, že polymorfismusjde ruku v ruce se zapouzdřením a obecně není nutně závislý na dě-


dičnosti.

Příklad 2.2.5 Příklad polymorfismu pomocí vynucené dědičnosti

class Osoba is ... end;subclass Student of Osoba is ... end;

var objOsoba : InstanceTypeOf(Osoba) := new Osoba;var objStudent : InstanceTypeOf(Student) := new Student;procedure f(x : InstanceTypeOf(Osoba)) is ... end;

objOsoba := objStudent;f(objStudent);

U staticky typovaných jazyků se situace komplikuje. Při překladuprogramu totiž nemusí být vždy možné správně odhadnout, s jakýmtypem objektu budeme pracovat (časná vazba neboli statická vazba), ačasná vazbaprotože se požadovaná operace určuje již během kompilace, nemusímezvolit vždy tu správnou. To se týká právě případů, kdy potřebujemepracovat s objekty na abstraktní úrovní a konkrétní implementaceoperací nás nezajímá. V těchto případech je nutné přistoupit k iden-tifikaci potřebné metody až v době běhu programu, kdy je ji nutnéinvokovat. Tento mechanismus se nazývá pozdní vazba, neboli dyna-pozdní vazbamická vazba, a k jeho implementaci se většinou používají tzv. tabulkyvirtuálních metod (VMT, ilustrace viz sekce 5.4.1 na straně 78). Pakkaždá instance třídy, která obsahuje virtuální metody (metody umož-ňující pozdní vazbu), obsahuje odkaz na VMT. Tato tabulka obsahujeukazatele na konkrétní metody, které jsou pro daný typ platné. Připřekladu se pouze tyto tabulky sestrojí a určí, který řádek VMT sepoužije.

U dynamicky typovaných OOJ jsou všechny metody virtuální.Všechny objekty totiž obsahují přímo reference na třídu, jíž je ob-jekt instancí, nikoliv pouze data (a odkaz na VMT). Metody příslušnéke zprávám se vyhledávají přímo v těchto třídách a jejich přítomnostnení žádným způsobem kontrolována v době kompilace. V případě,že za běhu programu nastane situace, kdy nebyla nalezena implemen-tace zprávy, dojde k výjimce16, kterou má samozřejmě možnost ošetřitdaný objekt i sám programátor. Algoritmus používaný při hledání avýběru metody pro reagování na přijatou zprávu se označuje jako me-chanismus směrování zpráv.

2.2.2 Prototypově orientované jazyky

Nejdůležitějšími vlastnostmi objektově orientovaných jazyků jsou za-pouzdření a polymorfismus. Díky těmto vlastnostem se objekty cho-vají jako uzavřené entity a v ideálním případě jen ony samy rozhodují

16Podrobnější informace ke konceptu výjimek jsou v sekci 5.3.7


o tom, jak naloží s přijatými zprávami od jiných objektů, tj. pracujíautonomně.

Ve většině objektově orientovaných jazyků objekty delegují zprávyna svoje třídy, ovšem objektové paradigma dovoluje mnohem většívolnost a existuje celá řada programovacích jazyků, které pracují nazákladě mnohem méně tradičních konceptů.

Velice perspektivní skupinu objektově orientovaných jazyků tvoříjazyky založené na prototypech. Tyto jazyky unifikují svůj návrh tím,že znají pouze jediný typ objektů a nevyčleňují samostatně objekty re-prezentující třídy. Rovněž objekty mají unifikovanou strukturu. Nyníse již nerozlišuje mezi instancemi, které obsahují nestatické proměnné,a třídami, které definují metody se sdíleným chováním, ale každý ob-jekt může obsahovat jak členské proměnné tak metody. Tyto složkyobjektu se označují jako sloty. slot

Sdílené chování

Pokud je objektu zaslána zpráva, prozkoumá množinu svých slotů apokusí se najít ten, který poslané zprávě odpovídá. To znamená, že sepoužije hodnota instanční proměnné nebo dojde k invokaci odpovída-jící metody.

Nové objekty se vytvářejí kopírováním existujících objektů, tzv.klonování. Klonování objektu se implicitně provádí technikou měl- klonováníkého kopírování. Teoreticky však může každý objekt přesně definovatvšechny své operace, tzn. že i všechny příbuzné objekty by používalysvé nezávislé kopie metod. Při změně kódu metody jednoho objektuby pak nedošlo ke změně korespondujících metod v objektech dalších.Tento přístup ovšem není příliš praktický, protože značně komplikujehromadné změny chování u příbuzných objektů.

V praxi je vhodné sdílené chování příbuzných objektů definovatpouze na jednom místě. To je důvod, proč byly v třídních jazycíchzavedeny třídy. Tuto operaci lze ovšem zajistit i bez přítomnosti třídtak, že všechny podobné objekty budou delegovat své přijaté zprávyna stejné objekty.

V případě rušení objektů se objektově založené jazyky příliš nelišíod třídních používajících garbage collector. Tj. pokud na objekt ne-existuje žádná reference (výjma reference z něho samotného), tak seprovede jeho zrušení, včetně zrušení jeho slotů, což jsou také pouhéreference. Rušení je dále samozřejmě aplikováno i na objekty odkazo-vané sloty zrušeného objektu v případě, že nejsou referencovány jinýmobjektem. Tímto lze likvidovat i celé shluky objektů.


( a + b) sum

4b

sum = 7

3a

parent*

Obrázek 2.2: Ukázka dvou objektů (se dvěma sloty) v rodičovském vztahu

Delegace

Delegace je proces velmi podobný obyčejnému zaslání zprávy. Naroz-delegacedíl od něj se ale při invokaci metody v delegovaném objektu neměníkontext. Tzn. že pokud je zpráva delegována na jiný objekt, je v tomtoobjektu nalezen odpovídající slot, a pokud je tímto slotem metoda, jespuštěn její kód s tím, že ukazatel na příjemce zprávy neodkazuje nadelegovaný objekt, jak by tomu bylo u zaslání zprávy, ale na objekt,který delegaci provedl.

Pokud je objektu poslána zpráva a ten ve svých slotech nenaleznežádný vhodný, provede delegaci zprávy na objekty, které jsou odkazo-vány speciálním typem slotů označovaným jako rodičovské sloty (ob-rodičovský slotrázek 2.2). Pokud ani rodičovský objekt neobsahuje vhodný slot, de-leguje zprávu dále na rodičovské objekty, tedy objekty referencovanérodičovskými sloty. I při této postupné delegaci referencuje odkaz napříjemce zprávy stále původního příjemce.

Třídy se sdíleným chování tak lze nahradit objekty, které obsahujípouze metody (tzv. rysy). Instanciace je pak simulována klonovánímtěchto rysů. Nové objekty pak odkazují svůj rys v rodičovském slotu.

Dědičnost

Pro objekty, které obsahují sdílené chování, a tím tak nahrazují nebodoplňují třídy, se používá označení rys (angl. trait). Provázáním jedno-rystlivých rysů rodičovskými sloty lze dosáhnout obdoby dědičnosti. Vícespecializovaný rys pouze pomocí rodičovského slotu odkáže obecnějidefinovaný rys, takže na něj deleguje neznámé zprávy.

Některé jazyky založené na prototypech dovolují umístit do ob-jektů více rodičovských slotů. Tímto způsobem dokáží elegantně vy-tvořit obdobu vícenásobné dědičnosti.

Protože hodnoty rodičovských slotů lze dynamicky měnit, lze do-sáhnout velmi zajímavého chování, které se v ostatních objektových


jazycích velmi špatně napodobuje. Jedná se o dynamickou dědičnost .Objekt má možnost v průběhu svého života bez omezení měnit svéchování. Statická typová kontrola v takovýchto podmínkách samozřej-mě naprosto ztrácí význam a tyto programovací jazyky jsou typovanédynamicky.

V praxi se příliš často nesetkáme se situací, kdy nějaký objekt zcelazmění svoje chování, ale případy, kdy je vhodné objekt dynamickyrozšířit o nové vlastnosti, jsou poměrně časté. Prototypově orientovanéjazyky se díky své dynamičnosti obejdou i bez použití sofistikovanýchnávrhových vzorů, resp. jejich implementace je triviální.

Prototypy

K tomu, abychom dosáhli plné náhrady funkce tříd ovšem samotnérysy nestačí. Problém je s instančními proměnnými, které jsou sou-částí samotných objektů a každý objekt musí mít jejich samostatnoukopii. Tento problém lze řešit více způsoby. Některé jazyky instančníproměnné přidávají do objektu a naplňují je standardními hodnotamiv konstruktoru rysu. Takto činí například JavaScript.

Druhou možností je rys doplnit ještě jedním objektem, který ob-sahuje sloty instančních proměnných s implicitními hodnotami a vesvém rodičovském slotu odkazuje rys. Nová instance se pak vytvoří na-kopírováním této šablony (viz obrázek 2.3). Šablony instancí se ozna-čují jako prototypy. Od nich tato třída jazyků také dostala své jméno. prototyp

První varianta je vhodnější pro jazyky orientované na zdrojovétexty, druhá varianta je efektivnější v jazycích s vizuálně orientovanýmvývojovým prostředím.

V syntaxi prototypově orientovaných jazyků nenalezneme pojmyjako rozhraní, mixins apod., ovšem dokáží je více než plně nahraditsvými stávajícími prostředky bez toho, aby pro ně musely vytvářetzvláštní syntaktické konstrukce.

Obecně platí, že jazyky založené na prototypech nemají tak bohatévýrazové prostředky, jako jiné objektové jazyky, ovšem svými schop-nostmi je díky své dynamičnosti často převyšují. Jejich prvním před-stavitelem byl jazyk SELF, který byl navržen v roce 1986 jako dialektSmalltalku založený právě na prototypech. Dnes v praxi nejčastěji po-užívaným zástupcem této skupiny je již zmiňovaný JavaScript, kterýse však v dalších ohledech od jazyka SELF značně odlišuje. Jazykyzaložené na prototypech v sobě skrývají velký potenciál. Jsou přede-vším velmi vhodné a názorné při vizuálním modelování, prototypovánía programování.

Nevýhodami těchto jazyků je vyšší režie (hlavně paměťová nároč-nost) a podstatně obtížnější vyhledávání objektů se stejným protoko-


traits point

point prototype

4 y

3 x

parent*

0 y

0 x

parent* clone

copyX: 3 Y: 4

( | p |p: self clone .p x: newX.p y: newY

p)

copyX: newX Y: newY

(x + point x. y + point y) translate: point

...clone

0 y

0 x

parent*

Obrázek 2.3: Ukázka rysu a prototypu, včetně použití (jazyk SELF)

lem.

Pojmy k zapamatovánítřída, instance, dědičnost, brzká (časná) a pozdní vazba, vo-lání/invokace metody, slot, rys, prototyp, delegace, klonování

Úlohy k procvičení:Vyberte si libovolný OOJ a prostudujte jeho syntaktické i sémantickémožnosti a vlastnosti. Popište, které vlastnosti zde popsané má akteré mu chybí, jak by byl klasifikován a jaké má výhody a nevýhody.

2.3 ZávěrObjektově orientované programování je v současnosti velmi dobrávolba pro většinu metodologií při tvorbě počítačových aplikací. Hlav-ním přínosem je zjednodušení problému dekompozice větších problémůna snadněji řešitelné podproblémy a dobrá reflexe reality přes dosta-tečně přesné abstrakce. Objektově orientované jazyky jsou vhodné pře-devším pro větší a velké projekty, kdy se již daň v podobě režie na

2.3. ZÁVĚR 35

objektový způsob práce s daty, pamětí a operacemi vyplatí. Velkýmplus je také dobrá róbusnost (udržovatelnost) a flexibilita. V budoucnumohou být OOJ nahrazeny jazyky s lepší implementací přímé podporykomponentních technologií či architektur orientovaných na služby.

ZávěrObjektově orientované paradigma je postaveno na komplexní datovéstruktuře—objekt, která sdružuje data a operace nad nimi do jedno-ho celku. Další koncepty jsou abstrakce, zapouzdření, polymorfismusa dědičnost, které přispívají ke správnému používání OO jazyka z po-hledu softwarového inženýrství.Model výpočtu se skládá pouze z příkazu (1) přiřazení a (2) zaslánízprávy, na kterou objekt reaguje spuštěním metody (implementacereakce na obdrženou zprávu) nebo vyvoláním výjimky o neporozu-mění zprávě. Zprávy, kterým objekt rozumí tvoří jeho protokol (roz-hraní).Podle způsobu vytváření nových objektů a podle způsobu implemen-tace konceptu dědičnosti rozlišujeme dva základní typy OOJ—(1)třídně založené jazyky a (2) objektově založené jazyky, které tvoříminoritní skupinu a zabývá se jimi pouze kapitola 2.2.2 (pojmy dele-gace, slot, rys).Zbylý text se soustředí na vlastnosti třídně založených jazyků, jakozpůsob vytváření/rušení objektů, dědičnost (jednoduchá, vícená-sobná, dědičnost rozhraní) a polymorfismus (časná vazba při překladuversus pozdní vazba za běhu programu).


2.4 Studijní literatura

Další zdroje

Jen málokdy se literatura zabývá pouze objektovým programovánímsamotným, ale většinou během výkladu základních principů zároveňprobírá syntaxi a sémantiku vybraného jazyka. Následující seznamstudijní literatury je příkladem několika takovýchto zajímavých pra-menů:• Merunka, V.: Objektové metody a přístupy - Smalltalk-80, učební

text.• Prata, S.: Mistrovství v C++, Computer Press, 2004, ISBN: 80-

251-0098-7.• Eckel, B.: Thinking in Java, 3rd Edition, Prentice-Hall, 2002.

Dostupné na URL http://www.mindview.net/Books/TIJ/ (únor 2006)

• Křivánek, P.: Squeak Smalltalk, 2003-2005.Dostupné na URL http://www.comtalk.net (únor 2006)

• Švec, M.: Programovací jazyk a aplikační prostředí SELF, FITVUT Brno, 2004.

Dostupné na URL http://www.fit.vutbr.cz/study/courses/TJD/public/0304TJD-Svec.pdf (únor 2006).Jak již bylo předesláno dříve, tak vysvětlení mnoha pojmů lze nalézttaké zde:• Wikipedia: Object-oriented programming, the free encyclopedia,

2005.Dostupné na URL http://en.wikipedia.org/wiki/Object-oriented_programming (listopad 2005).

Kapitola 3

Formalismy a jejich užití

Tato kapitola seznamuje s možnostmi základních formálních pro-středků pro popis syntaxe a sémantiky objektově orientovaných ja-zyků.


Cíle kapitolyHlavní cíl této kapitoly je seznámit čtenáře se základními formálnímiprostředky, které se používají při popisu syntaxe a sémantiky ob-jektově orientovaných jazyků. Pro ukázku formálního popisu OOJ sidefinujeme jednoduchý netypovaný ς-kalkul (čti sigma kalkul). Po-chopení ς-kalkulu je dostačující na pasivní úrovni, tedy se schop-ností interpretovat jednoduché výrazy tohoto modelu a chápat jejichvýznam. Nakonec naznačíme vztah grafického modelovacího jazykaUML s objektově orientovanou analýzou (OOA) a návrhem (OOD).

Průvodce studiemStudium této kapitoly vyžaduje znalost pojmů jako je Backus-Naurova forma pro popis syntaxe programovacího jazyka a zákla-dní znalosti týkající se popisu formálních modelů (formální jazyky,logika). Text obsahuje matemicky náročnější pasáž doplněnou jedno-duchými ilustračními příklady.

37

38 KAPITOLA 3. FORMALISMY A JEJICH UŽITÍ

Obsah3.1 Formální základ popisu objektově oriento-

vaného jazyka . . . . . . . . . . . . . . . . . . 39

3.2 ς-kalkul . . . . . . . . . . . . . . . . . . . . . . 39

3.2.1 Syntaxe a sémantika ς-kalkulu . . . . . . . . 40

3.2.2 Příklady . . . . . . . . . . . . . . . . . . . . 42

3.3 UML - formální vizuální jazyk . . . . . . . . 44

3.3.1 Výhody a nevýhody formálního návrhu . . 45

3.4 Závěr . . . . . . . . . . . . . . . . . . . . . . . 45

3.1. FORMÁLNÍ ZÁKLAD POPISU OBJEKTOVĚ ORIENTOVANÉHO JAZYKA 39

Výklad

3.1 Formální základ popisu objektověorientovaného jazyka

Podobně jako u modulárních jazyků i u OOJ není formální základnezbytný pro jeho návrh a v minulosti býval opomíjen. Z imperativ-ních OOJ můžeme jako příklad jazyka s formálním základem uvéstjazyk OCAML (odvozený od ML), který se úzce váže na jazyk SMLs již existujícím formálním popisem. Tyto jazyky většinou obsahují ivlastnosti známé z funkcionálního programování.

Mnohem příznivější situace z tohoto hlediska je u deklarativníchjazyků, kde je formální základ poměrně dobře rozpracován v podoběrůzných objektových kalkulů (netypovaných i typovaných), napříkladtzv. ς-kalkul a jeho varianty.

Formální základ lze opět rozdělit na dvě popisované oblasti — syn-taxe a sémantika. Popis syntaxe OOJ využívá prostředků známých již syntaxez předchozích programovacích paradigmat, tedy především kombinace(E)BNF, bezkontextových gramatik a slovního výkladu doplněnéhoo příklady. Tato nenáročnost je dána podobnou syntaktickou struk-turou, kdy OOJ byly doplněny jen o několik nových klíčových slov av některých jazycích nebylo nutné ani toto. Naopak sémantika jazyka sémantikadoznala zásadních a rozsáhlých změn či spíše zavedení úplně novýchvýznamů a množství kombinací. Bohužel ve většině OOJ (předevšímtěch imperativních) je velmi obtížné složitou sémantiku formálně po-psat, a proto se většinou využívá pouze vícevrstvý slovní popis s množ-stvím demonstračních příkladů. Hlavním úskalím je, že mohou zůstatutajeny některé okrajové sémantické vlastnosti jazyka, když se na něv textovém popisu pozapomene nebo jejich vyjádření je pro čtenářenejednoznačné.

3.2 ς-kalkul

V následujících několika odstavcích se budeme zabývat jednoduchouvariantou čistého netypovaného objektového kalkulu (symbol ς čti jakosigma), abychom názorně demonstrovali příklad formálního základuobjektově orientovaného jazyka.


3.2.1 Syntaxe a sémantika ς-kalkulu

Na objekty budeme nahlížet jako na primitivy s definovanou sémanti-kou.

Objekt se skládá z atributů (metod a paměťových buněk pro hod-noty). Nad každým objektem je potom nutno implementovat minimál-ně dva typy sémantických akcí — výběr atributu (exekuce či invokacemetody/návrat hodnoty uložené v objektu) a změnu atributu (změnutěla metody/změna hodnoty v paměťové buňce objektu).

ς-kalkul obsahuje minimální množinu syntaktických konstrukcí aSyntaxe ς-kalkuluvýpočetních pravidel při zachování výpočetní úplnosti.

V celé této podkapitole budeme používat symbol � pro ekvivalencipodle definice a symbol ≡ pro syntakticky identické termy.

Každý program či výraz v ς-kalkulu je popsán jako ς-term, kterývzniká z ς-podtermů následujícího tvaru:

Nechť a, b1, . . . , bn jsou ς-termy, pak i následující zápisy jsouς-termy:

1. Proměnná

x

2. Vytvoření objektu (obsahuje jen metody bez parametrů s návěš-tími li; jediný a povinný formální parametr xi slouží pro pojme-nování objektu příjemce zprávy1 s rozsahem platnosti v bezpro-středně následujícím těle metody)

[li = ς(xi)bi∈1...n

i ],

kde2 každé li a lj jsou navzájem různé pro i �= j, n ≥ 0 a

kde ς(xi)bi je metoda s pojmenováním objektu vlastníka me-tody návěštím xi a s tělem této metody bi, kde je xi vázanouproměnnou.

3. Invokace metody3 (spuštění metody) / výběr atributu

a.l

4. Modifikace metody / modifikace atributu (s funkcionální séman-tikou, tj. výsledkem je nový objekt se změněnou definicí patřičnémetody)

a.l ⇐ ς(x)e′

1V praxi se objekt příjemce zprávy označuje v kódu vlastních metod pseudo-proměnnou nebo klíčovým slovem this nebo self.

2Pro zkrácení zápisu obecného objektu budeme používat l i∈1..ni pro vyjádření

posloupnosti l1, l2, . . . , ln.3ς-kalkul nepracuje s mechanismem zasílání zpráva.

3.2. ς-KALKUL 41

Příklad 3.2.1 Ukázka definice objektu pomocí ς-kalkulu:

o = [l1 = ς(x1)[], l2 = ς(x2)x2.l1]

Objekt označený o obsahuje dvě metody l1 a l2, kde první vracíprázdný objekt [] a druhá invokuje metodu l1.

V příkladu 3.2.1 vidíme, že jediné operace, které lze s objekty pro-vádět, jsou invokace metody jejího hostovského objektu (tečková no-tace pro volání metody objektu) a nebo její modifikace (symbol ⇐).A až na proměnnou a literál pro zápis objektu (v hranatých závor-kách) není v ς-kalkulu už žádná jiná syntaktická konstrukce. Syntaxiještě doplníme kulatými závorkami pro explicitní vyjádření priorit arozsahu platnosti jednotlivých proměnných. Také poznamenejme, ženezáleží na pořadí definice metod při zápisu literálu objektu. Písmenoς je použito pro navázání hostovského objektu metody na proměn-nou uzavřenou v následujících závorkách. Syntaktická konstrukce ς(x)bznačí vázání proměnné x na rozsah podtermu b. V nejednoznačnýchsituacích se vázání proměnné vztahuje na největší možný podterm bez-prostředně vpravo od ς(x). Tedy například, ς(x)x.l znamená ς(x)(x.l)a ne (ς(x)x).l.

Pro formální popis primitivní sémantiky ς-kalkulu potřebujeme volná a vázaná pro-měnnádefinice pojmu volná a vázaná proměnná v libovolném ς-termu. Vol-

nost proměnné určuje rozsah platnosti této proměnné. Proměnná můžebýt v daném výrazu buď volná nebo vázaná, ale ne obojí zároveň.

Mějme konečnou množinu proměnných P, množinu všech platnýchvýrazů ς-kalkulu E a funkci FV : E → 2P počítající množinu volnýchproměnných ze zadaného výrazu definovanou takto:

1. FV(ς(y)b) � FV(b)− {y}2. FV(x) � {x}3. FV([li = ς(xi)b

i∈1...ni ]) �

⋃i∈1...n FV(ς(xi)bi)

4. FV(a.l) � FV(a)

5. FV(a.l ⇐ ς(x)b) � FV(a) ∪ FV(ς(x)b)

Dalším dílčím mechanismem využitým při popisu sémantiky ς- substitucekalkulu je substituce (nahrazení) termu c za všechny volné výskytyproměnné x v libovolném ς-termu b, značíme (b{{x←c}}), a definujemeji takto:

1. (ς(y)b){{x←c}} � ς(y′)(b{{y←y′}}{{x←c}}) pro y′ /∈ FV (ς(y)b)∪FV (c) ∪ {x}


2. x{{x←c}} � c

3. y{{x←c}} � y pro y �= x

4. [li = ς(xi)bi∈1..n

i ]{{x←c}} � [li = (ς(xi)bi){{x←c}}i∈1..n]

5. (a.l){{x←c}} � (a{{x←c}}).l6. (a.l ⇐ ς(y)b){{x←c}} � (a{{x←c}}).l⇐ ((ς(y)b){{x←c}})

Přejmenování y za y′ a podmínka pro y′ v bodě 1 nám reflektujípřirozené pravidlo, že žádná volná proměnná x se substitucí nesmí státvázanou proměnnou.

Výpočet libovolného ς-termu se zapisuje formou posloupnosti re-primitivní sémantikaς-kalkulu dukčních kroků. Pokud se tedy b redukuje v jednom kroku na c, tak

píšeme b � c.Nechť o ≡ [li = ς(xi)b

i∈1..ni ] je objekt s navzájem různými návěš-

tími všech jeho metod.o.lj � bj{{xj←o}}, (j ∈ 1..n) je tzv. redukce invokace ao.lj ⇐ ς(y)b � [lj = ς(y)b, li = ς(xi)b

i∈(1..n)−{j}i ], (j ∈ 1..n) je tzv.

redukce modifikace.

3.2.2 Příklady

Prvním příkladem je redukce objektu s jedinou metodou s návěštíml, jejímž tělem je prázdný objekt [], a jedná se tedy z praktickéhohlediska o datový člen objektu:Mějme objekt o1 � [l = ς(x)[]]. Při invokaci metody l v tomtoς-kalkulu se provede následující redukce o1.l � []{{x← o1}} ≡ [], anebo při modifikaci metody se například o1.l ⇐ ς(x)o1 � [l = ς(x)o1]a vznikne nový objekt s upravenou metodou l.

S využitím substituce „sama-za-sebe“ lze zkonstruovat i nekonečnývýpočet, a to bez explicitního použití rekurze:Mějme objekt o2 � [l = ς(x)x.l], který při invokaci metody l budedonekonečna provádět redukci o2.l � x.l{{x←o2}} ≡ o2.l � . . .

V ς-kalkulu může metoda také například vracet objekt, ve kterémbyla invokována:Mějme objekt o3 � [l = ς(x)x], pak o3.l � x{{x←o3}} ≡ o3.

Ze známých praktických jazyků má k tomuto formálnímu modeluvelice blízko např. jazyk SELF, který taktéž nerozlišuje mezi datovýmipoložkami a metodami objektu, ale zavádí jednotný pojem slot.

3.2. ς-KALKUL 43

Další dva příklady demonstrují možnosti ς-objektů modifikovat svévlastní členské metody.

Mějme tedy např. o4 � [l = ς(y)(y.l⇐ ς(x)x)], pak o4.l � (y.l⇐ς(x)x){{y←o4}} ≡ (o4.l ⇐ ς(x)x) � [l = ς(x)x] ≡ o3.

Poslední příklad ilustruje techniku zálohování obsahu objektu (me-toda backup) před jeho změnou a následující možnost obnovy stavuobjektu z této zálohy (metoda retrieve).

o � [retrieve = ς(s1)s1,backup = ς(s2)s2.retrieve⇐ ς(s1)s2,. . .

]

Metoda pro obnovení (retrieve) je inicializována tak, aby vracelaobjekt samotný, protože zatím nebyla provedena žádná záloha. Dalšímmožným řešením by bylo vracet v takovém případě například prázdnýobjekt. Všimněme si, že backup ukládá objekt obsažený ve formálnímparametru s2, který v daný okamžik obsahuje objekt aktuální v doběinvokace metody backup. Kdežto v době volání retrieve je aktuálníobjekt pojmenovaný s1. Retrieve tedy vrací objekt přesně, jak bylnaposledy zazálohován.

o′ � o.backup = [retrieve = ς(s1)o, . . .]o′.retrieve = o

Protože tato záloha opět obsahuje předchozí zálohu, lze se kaská-dovým voláním propracovat k libovolné záloze.

Složitější příklady, jako definice objektově orientovaných přiroze-ných čísel pomocí ς-kalkulu nebo příklad kalkulačky, vyžadují pro po-chopení další rozšíření vlastností (jako například propracovanější ope-rační sémantiku a transformace z λ-kalkulu; viz kapitola o funkcionál-ním programování). Dále lze ς-kalkul rozšířit o další vlastnosti známéz většiny OOJ, jako je dědičnost, třídy, typy, atd.


Úlohy k procvičení:

1. Z hlediska syntaxe i vyjadřovacích schopností porovnejte λ-kalkul známý z funkcionálního programování (viz text moduluo funkcionálním programování) a ς-kalkul, který byl popsánv této kapitole.

2. Dále doplňte popis zde uvedených příkladů a výrazů ς-kalkulu,například o určení volných a vázaných proměnných, upřesněníuskutečněných substitucí.

3. Nakonec se pokuste vymyslet vlastní jednoduchý správný výrazς-kalkulu, který se v tomto textu nevyskytuje a pokuste se jejvyhodnotit (redukovat).

Pojmy k zapamatováníς-kalkul, vytvoření objektu, invokace metody, modifikace metody,substituce, primitní sémantika

Klíč k řešení úlohK prvnímu bodu předchozích úloh řekněme, že libovolný výraz ς-kalkulu lze převést na ekvivalentní výraz λ-kalkulu, což se často vyu-žívá například při formální verifikaci, kdy tak máme k dispozici většívýběr z podpůrných nástrojů.

3.3 UML - formální vizuální jazyk

Jedním z možných formalismů využívaných při objektově orientovanéanalýze (OOA) a návrhu (OOD) je grafický jazyk UML, jehož syn-taxe a částečně i nejčastěji používaná sémantika bude stručně zopako-vána v následující kapitole 4 s důrazem na popis entit a vlastnostítýkajících se OOP. Tento formalismus tedy není přímo užíván propopis syntaxe nebo sémantiky objektově orientovaného programova-cího jazyka, ale spíše objektových modelů a návrhů systémů. Přímove specifikaci UML je zřetelně naznačeno, že UML v žádném případěnesměřuje k nahrazení klasických programovacích jazyků zaměřenýchna zdrojové texty. Hlavním důvodem je silně abstraktní sémantika vět-šiny konstrukcí v UML a obtížné vyjadřování velmi specifických vazeb,které se efektivněji dají vyjádřit prostřednictvím algoritmického tex-tového zápisu.

Jeden z hlavních důvodů, proč je výhodné zavádět různé formalis-my obecně (i v OOP) je vidina automatické nebo částečně automatické

3.4. ZÁVĚR 45

formální verifikace. Problémy verifikace lze pak převést na problém zá-pisu celé aplikace prostřednictvím určitého matematického formalismu(např. ς-kalkul). Toto je však mnohdy velmi náročný úkol.

Druhým méně náročným požadavkem je využívat formalismus naúrovni návrhu (angl. formal design) a ověřovat pouze správnost natéto úrovni. Problémem je pak pouze zajištění správnosti transformaceonoho návrhu do výsledné implementace.

Na druhé variantě staví většina procesů OOA a OON využívajícíchUML a nástroje pro formální verifikaci (příp. validaci) navrženýchUML modelů.

Většina modelů UML je reprezentována grafickými diagramy,z nichž stěžejní jsou diagramy tříd, objektů (instancí), aktivity, sta-vové, případů použítí a mnoho dalších.

3.3.1 Výhody a nevýhody formálního návrhu

Jazyk pro popis návrhu je nezávislý na implementačním jazyce, ob-sahuje konstrukce pro popis struktury systému a komunikace mezielementy systému. Takovéto návrhy často slouží jako vstup pro au-tomatické generátory zdrojového kódu, a jak již bylo nastíženo, takéjako vstup pro verifikační nástroje.

V tomto okamžiku přichází do hry problémy s udržováním/reflexízměn ve zdrojových kódech také v korespondujících formálních mode-lech, což je často neautomatizovatelný úkol.

Na druhou stranu jazyk jako například UML 2.0 není výpočetněúplný. Neklade si totiž za cíl nahradit současné implementační jazyky,ale zaměřuje se na popis specifikace, návrhu a samotného procesu vý-voje. Kvůli vysoké míře abstraktnosti UML se také velmi rozcházejírůzná rozšíření třetích stran (např. kompletní generátory zdrojovýchkódů nebo doplňky pro popis systémů pracujících v reálném čase).

3.4 Závěr

Kapitola nastínila čtenáři možnosti formálního popisu objektově orien-tovaných jazyků včetně jejich sémantiky. Pro pokročilejší studenty,také nastínila vztah mezi ς-kalkulem a čistě objektově orientovanýmijazyky, které jsou založené na objektech (prototypově orientované, vizsekce 2.2.2). Probíraný ς-kalkul byl doplněn řadou jednoduchých pří-kladů pro podporu pochopení matematicky náročné látky.


ZávěrV úvodu kapitoly je zmíněn význam formálního základu jazyka promožnosti automatické verifikace. Jako reprezentant je zvolena jed-noduchá varianta ς-kalkulu zapisující objekty jako soubory metod(uzavřené do hranatých závorek). Metody jsou definovány jako ς-termy, které mohou být redefinovány jiným ς-termem nebo invoko-vány. Všechny metody mají právě jeden formální parametr. Na tentoformální parametr je při invokaci či modifikaci metody navázán ob-jekt vlastnící danou metodu.V textu je dále uvedena definice substituce a funkce pro určení vol-ných (zbýlé jsou vázané) proměnných ve výrazu ς-kalkulu. Posledníteoretičtější část obsahuje popis primitivní sémantiky, jež je demon-strována na komentovaných příkladech.Jako alternativní formální popis při objektově orientované analýze anávrhu lze využít populární vizuální jazyk UML.

Další zdrojeKnih obsahujících srozumitelně popsanou teorii o formálním popisuobjektově orientovaných jazyků příliš mnoho nenajdete a většinou sejedná o anglicky psané publikace téměř na vědecké úrovni:• Abadi, M., Cardelli, L.: A Theory of Objects, Springer, New York,

1996, ISBN 0-387-94775-2.Literatura týkající se UML je součástí zdrojů k následující kapitole.

Kapitola 4

UML

Tato kapitola přehledově opakuje základní syntaxi a nejčastější sé-mantiku modelovacího jazyka UML, který se v současnosti intenzivněvyužívá při analýze, návrhu a dokumentaci objektově orientovanýchsystémů (aplikací).


Cíle kapitolyHlavní cílem této kapitoly je poskytnout studujícímu ucelené astručné informace o jazyku UML a jeho nejčastěji využívaných mož-nostech. Celá kapitola je psána formou rešerše shrnující jinak velmiobjemný popis syntaxe, sémantiky a technik používání UML. Nej-větší důraz je kladen na reprezentaci pojmů a vztahů, které jsmezavedli a vysvětlili v kapitole 2 a případně rozšíříme v kapitole 5.

Průvodce studiemStudium této kapitoly vyžaduje ovládání elementárních dovednostípři tvorbě informačních systémů a aplikací, včetně povědomí o život-ním cyklu softwarového produktu. Pro hlubší studium či detailnějšízopakování jazyka UML si dovolím čtenáře odkázat na referenční astudijní literaturu na konci této kapitoly, protože jazyk UML je pouzedoplňující nástroj vhodný pro zvládnutí a pochopení objektové orien-tace, a není tudíž hlavním tématem tohoto modulu o OOP.

47

48 KAPITOLA 4. UML

Obsah4.1 Co je to UML? . . . . . . . . . . . . . . . . . 49

4.2 Modelování v UML . . . . . . . . . . . . . . 49

4.2.1 Stavební bloky . . . . . . . . . . . . . . . . 50

4.2.2 Diagramy tříd a objektů . . . . . . . . . . . 51

4.2.3 Další diagramy UML . . . . . . . . . . . . . 56

4.3 Závěr . . . . . . . . . . . . . . . . . . . . . . . 60

4.1. CO JE TO UML? 49

Výklad

4.1 Co je to UML?

Jazyk UML (Unified Modeling Language) vznikl jako snaha sjedno-tit a standardizovat metodologie a metody objektově orientovanéhonávrhu a realizace aplikací přibližně v roce 1996 (Booch, Rumbaugh,Jacobson). V roce 1997 byl návrh UML přijat organizací OMG (ObjectModeling Group, např. [26]) jako první průmyslový standard objek-tově orientovaného jazyka pro vizuální univerzální modelování. UMLvšak není přímo metodologií návrhu systému, ale pouze prostředkempro tvorbu modelů systému, a bývá často součástí nových metodologií.

Definice 4.1.1 UML je jednotný grafický (vizuální) jazyk pro jed- Definice!notnou specifikaci, vizualizaci, konstrukci a dokumentaci při objektověorientované analýze a návrhu (OOA&D) i pro modelování organizace(business modelling).

UML umožňuje modelování softwarových aplikací stejně jako dal-ších systémů (např. obchodní procesy) jako kolekce spolupracujícíchentit (objektů). Základní cíl modelování je vizualizace, specifikacestruktury a chování navrhovaného systému. Napomáhá dekompono-vání systému na dílčí části a zároveň nutí určit i jejich kompetence,vzájemné závislosti a interakci s okolím.

Úspěch tohoto způsobu modelování nejen objektově orientovanýchsystémů dokládájí probíhající práce na nových verzích (začátkem roku2008 se pracovalo na verzi UML 2.2).

4.2 Modelování v UML

Popis návrhu systému prostřednictvím jazyka UML se skládá většinouz několika pohledů. Pohledem (angl. view) nazýváme projekci systému pohled(či jeho modelu) na jeden z jeho klíčových aspektů a znázorňujeme jejjedním či více diagramy UML. Základní pohledy jsou strukturální,datový, pohled na chování a rozhraní. Pohledy respektive diagramylze rozdělit také na analytické („Co bude systém dělat?“) a návrhové(„Jak to bude dělat?“). Diagram UML je struktura podobná obec- diagramnému grafu obsahující množinu grafických prvků (vrcholy) propoje-ných vztahy (hrany).

50 KAPITOLA 4. UML

4.2.1 Stavební bloky

Pro přehlednost uvádíme krátký přehled základních stavebních blokůdiagramů UML:

1. Prvky (neboli předměty, angl. things, či abstrakce, entity)

Strukturní: třída, případ použití, komponenta

Chování: interakce, stav

Seskupování: modul, balíček, podsystém (angl. package)

Doplňkové: komentáře a poznámky

2. Vztahy (angl. relationships) především strukturálních a sestavo-vacích prvků

Asociace (spojení mezi prvky)

Závislost (změna v jednom prvku ovlivní jiný závislý prvek)

Agregace, Kompozice (vyjádření dekompozice prvku na pod-části)

Generalizace (vztah mezi obecnějším a specifičtějším prv-kem)

Realizace (vztah mezi předpisem a jeho uskutečněním)

Z předchozích prvků potom mohu sestrojit následující UML dia-gramy, které mohou být využívány při tvorbě různých UML pohledů:

a) model struktury (statický aspekt modelu) - popisuje důležitéentity systému a jejich souvislosti

Diagram tříd

Diagram komponent

Diagram rozmístění zdrojů (nasazení)

b) model chování (dynamický aspekt modelu) - popisuje životnícyklus entit a jejich spolupráci

Diagram objektů

Diagram případů použití

Diagram interakce: diagram sekvence, diagram spolupráce

Stavový diagram

Diagram aktivit

4.2. MODELOVÁNÍ V UML 51

+operace(in parametry) : NavratovyTyp

-atribut : Typ = hodnota

Trida ZkracenaReprezentaceTridy

atribut : Typ = hodnota

Object1 : Trida

ObjektZkracene : Trida

Obrázek 4.1: Symboly UML pro třídu, objekt a jejich zkrácené verze

Některé diagramy mají spíše statický charakter (diagram tříd čikomponent) a jiné jsou primárně určeny k zachycování dynamickýchvlastností popisovaného systému (diagramy interakce, stavové dia-gramy, diagramy aktivit).

Ve všech syntaktických konstrukcích UML je většina vlastností ne-povinná, aby byla v tomto jazyce maximálně podpořena myšlenkaefektivního modelování a prototypování při návrhu systému. Neuve-dení těchto vlastností má samozřejmě vliv na kvalitu popisu modelu,ale nikoli na jeho validitu vůči syntaxi či sémantice UML.

4.2.2 Diagramy tříd a objektů

Nejpodrobnější popis si zaslouží prvky reprezentující třídu a objekt, zekterých se potom pomocí vztahů komponují diagramy tříd a objektů.Proto si v následujícím oddíle popíšeme tyto dvě entity detailněji neždalší používané stavební bloky UML.

Reprezentace tříd a objektů v UML

Na obrázku 4.1 najdeme symboly reprezentující třídu, objekt a jejichzkrácené symboly. Třída je rozdělena na tři bloky obsahující název, třídaseznam atributů a seznam operací. Objekt obsahuje pouze podtržený objektidentifikátor objektu s případným určením třídy a seznam atributůs přiřazenými hodnotami.

Atributy jsou prvky objektu (třídy), u nichž lze specifikovat typ atribut(obor hodnot), jméno (identifikátor), implicitní hodnotu a viditelnost.Při implementaci atributy často odpovídají instančním (třídním) pro-měnným nebo vlastnostem. Pro typy v UML zápisu se nutně nemusívyužívat pouze datové typy konkrétního cílového implementačního ja-zyka. UML umožnuje u atributu specifikovat také režim možného pří-stupu pro čtení a zápis (např. jen pro čtení, jen pro zápis, pro čteníi zápis). Pro vyjádření atributů jen pro čtení se používá znak „/“ anazývají se odvozenými atributy.

Operace ve většině případů odpovídají metodám třídy a jedná operacese o pojmenováné chování třídy (potažmo instance třídy). Operacejsou popsány identifikátorem, modifikátorem viditelnosti, seznamemformálních parametrů a návratovým typem. Výjma identifikátoru jsou

52 KAPITOLA 4. UML

+zjistiPlochu()#pocetUsecek() : int+pocetInstanciPolygonu() : int

-plocha

Polygon

+sin(in uhel : double) : double+cos(in uhel : double) : double

«utility»MatematickeFunkce

+addSubclass()

-name : string-subclasses : Class

«metaclass»Class

Obrázek 4.2: Abstraktní třída a dvě ukázky tříd se stereotypem

ostatní položky nepovinné. Každý parametr může obsahovat vstupně-výstupní modifikátor („in“ pro vstupní, „out“ pro výstupní a „inout“pro vstupně-výstupní parametry), formální jméno a typ.

V UML najdeme tři typy viditelnosti atributů a operátorů (v zá-vorkách je uvedena používaná prefixová značka):

soukromá viditelnost (-) atribut/operace je k dispozici pouzeuvnitř třídy, kde je definován(a);

chráněná viditelnost (#) přístup je omezen pouze na instance třídpřímo či nepřímo zděděných od vlastníka atributu/operace;

veřejná viditelnost (+) k atributu/operaci lze přistupovat bezomezení z libovolného jiného objektu.

Třídní atributy a operace jsou značeny podtržením (Neplést s pod-třídní atributy a ope-race tržením identifikátoru v případě objektu!).

Abstraktní operace, u kterých nemá smysl mít v dané třídě kon-abstraktní operace atřída krétní implementaci ale pouze definici, jsou značeny kurzívou. Stej-

ně je tomu tak u abstraktní třídy na obrázku 4.2 (někdy je kvůlilepší přehlednosti vloženo do pole pro název třídy také klíčové slovo{abstract}. Připomeňme, že abstraktní třídy nelze instanciovat.Stereotypy tříd

Vlastnosti třídy lze upřesnit pomocí tzv. stereotypu, což je ozna-čení speciálního druhu třídy se specifickým účelem. Stereotyp bývázapisován nad název třídy do francouzských uvozovek (viz obr. 4.2).

Často se v OOP setkáváme s třídami, které nejsou primárně určenypro popis atributů a operací jejích instancí, ale pro sdružení obecněpoužívaných funkcí (např. matematické). Takovýto význam třídy za-pisujeme stereotypem «utility», neboli balíček nástrojů. V praxi sez této třídy nikdy netvoří instance (všechny členy má statické) nebo sevytváří pouze jediná instance (tzv. singleton, viz podkapitola 5.4.3).Někdy se využívá pro tvorbu obálek pro kód převzatý ze starších ne-objektových jazyků (např. C nebo Pascal) a vede na tzv. objektovězaložené programování.

Stereotyp rozhraní slouží pro popis speciální třídy, která slouží prorozhraní


+tiskni()

-SeznamPolicek

Formular

+tiskni()

-tvar

GrafickyPrvek

+tiskni()

«interface»Tisk

Obrázek 4.3: Ukázka třídy se stereotypem rozhraní a jeho dvě realizace

+pridej(in prvek : TypPrvku)

-prvky : TypPrvku

Kolekce

TypPrvku

+pridej(in prvek : Auto)

-prvky : Auto

Parkoviste«bind»(Auto)

+pridej(in prvek : Zbozi)

-prvky : Zbozi

NakupniKosik «bind»(Zbozi)

Obrázek 4.4: Parametrizovaná třída Kolekce a dvě konkrétní třídy s na-vázaným parametrem na třídy Auto a Zbozi

sdružení množiny operací, jejichž rozhraní (deklarace operací, proto-kol) vyváží ostatním třídám, které toto chování (rozhraní) pak povinněimplementují (viz obrázek 4.3, uprostřed).

Méně používanými stereotypy jsou «metaclass», «type»,«implementation class» a další.

Parametrizovaná třída (generická třída, třída šablony)Některé OOJ umožnují programovat s využitím parametrizova- parametrizovaná třída

ných tříd, které uvnitř pracují s jedním nebo více v době psaní kóduneznámými datovými typy nebo třídami. Na obrázku 4.4 vidíme třídušablony s jedním formálním parametrem zapsaným ve speciální ko-lonce v pravém horním rohu názvu třídy. Pokud provedeme navázáníformálního parametru třídy na konkrétní datový typ či třídu, tak zís-káme novou třídu, kterou s původní parametrizovanou spojíme orien-tovanou úsečkou s návěštím «bind» a jménem dosazeného typu zapožadovaný formální parametr parametrizované třídy.

Třída může dále obsahovat textové i grafické poznámky, klíčováslova (např. abstract), stereotypy a dodatečné informace pro doku-mentační účely (např. jméno zodpovědného programátora, číslo po-slední verze).

Diagram tříd

V předchozí sekci jsme si popsali, jak znázorňujeme třídy, objekty a je-jich varianty. Nyní se tedy zaměříme na čtyři základní statické vztahy,které tyto entity propojují v diagramu tříd. Všimněme si také obec-nosti těchto vztahů, které se neomezují pouze na výskyt v diagramechtříd, ale lze je uplatnit například i v diagramu případů použití a dal-ších.

54 KAPITOLA 4. UML

Zamestnanec

-pracovnik1..*

-vedouci pracovnik

1Pracuje

Spolecnost

Osoba*

1..*Prace

Obrázek 4.5: Asociace s názvem a násobnostmi, pojmenovaná reflexivníasociace s rolemi

Definice 4.2.1 Diagram tříd je graf symbolů tříd, rozhraní, seskupeníDefinice!a dalších strukturních prvků propojených statickými vztahy (asociace,závislost, agregace, kompozice, generalizace, realizace).

Násobnosti vztahu se udávají pro upřesnění obecného vztahu anásobnosti vztahubývají značeny na obou koncích úsečky (násobnosti označme a, b),která znázorňuje vztah mezi třídami A a B. Násobnost b v případědiagramu tříd odpovídá na otázku „S kolika objekty třídy B je v relacijeden objekt třídy A?“ a analogicky přesně naopak se dotazujeme nanásobnost a. Násobnost se v UML zapisuje takto:

1. konstanta k (například 0, 1, 2, ...)

2. libovolné neomezeně velké nezáporné celé číslo (značíme *)

3. interval složený z konstanty určující dolní hranici D a horní hra-nici H , kdy platí D < H nebo H může být ∗ (například 0..* prolibovolnou násobnost, 0..1 pro volitelnost, apod.).

Asociace (angl. association) je obecná relace mezi dvěma či víceasociacetřídami zakreslená úsečkou spojující tyto třídy. Asociace může být po-jmenována pro upřesnění svého významu. Oba konce asociace mohouobsahovat popis role připojené třídy a násobnost vztahu na danémkonci (obr. 4.5).

Atributy a operace se vztahem přímo k samotné asociaci sdru-žujeme do tzv. asociační třídy, která je znázorněna symbolem třídypropojené přerušovanou úsečkou s úsečkou vztahu (viz obrázek 4.6).

Na obrázku 4.6 vidíme také případ vícenásobné asociace, kdy se navztahu podílejí více jak dvě třídy. Vztah je reprezentován prázdnýmkosočtvercem a úsečkami vedoucími do jednotlivých tříd vztahu.

Realizace (angl. realization) je vztah mezi rozhraním a implemen-realizacetační třídou, který značíme čárkovanou šipkou směřující k rozhraní, jakto znázorňuje obrázek 4.3.

Generalizace (angl. generalization) je statický vztah mezi obe-generalizacecnější a specifičtější entitou, v případě tříd mezi rodičovskou třídou


Tym Hrac

Rok

tym*

brankar*

se

zon

a*

goly danegoly obdrzenevyherproherremiz

Zaznam

Obrázek 4.6: Ukázka vícenásobné asociace i s asociační třídou

Trojuhelnik

Tvar

CtverecBod

Polygon

DopravniProstredek

Auto Lod

Hydroplan

Letadlo

Ge

ne

raliz

ace

Sp

ecializa

ce

Obrázek 4.7: Jednoduchá a vícenásobná generalizace (dědičnost)

a třídou potomka. Jelikož je rodičovská třída obecnější než třídy po-tomků a šipka směřuje od potomka k rodiči, tak tento vztah nazý-váme generalizace (zobecnění). Pokud bychom postupovali opačnýmsměrem, půjde o specializaci, která se však v UML nepoužívá.

Popiskům generalizace říkáme diskriminátory dědičnosti a sloužípro upřesnění oblasti generalizace při dědění (např. u třídyDopravníProstředek a potomků Auto a Kolo bude diskriminátor dě-dičnosti typPohonu).

Grafický zápis neklade žádné omezení na modelování pomocí jed-noduché či vícenásobné dědičnosti (viz obrázek 4.7).

Agregace vyjadřuje složení entity ze skupiny komponentních en-tit. Vztah kreslíme jako úsečku na straně celku zakončenou prázdnýmkosočtvercem (pevná násobnost je 1; neznačíme) a na druhém koncišipkou s případnou násobností.

Kompozice je speciální případ agregace, kdy každá komponentnítřída smí náležet pouze jednomu celku (někdy tzv. silná agregace). Na

56 KAPITOLA 4. UML

Polygon-barva-textura

Grafika

Bod

1

-grafickyBalik

1

1

+body

3..*{ordered}

tvoren

Obrázek 4.8: Agregační a kompozitní vztah

rozdíl od agregace zakreslujeme na straně kompozitní třídy vyplněnýkosočtverec.

Agregaci a kompozici lze někdy považovat za speciální případyasociačního vztahu. Příklad obou z nich je na obrázku 4.8.

Závislost (angl. dependency) je vztah mezi prvky, v níž změnazávislostjednoho elementu (dodavatele) má vliv na závislý element (klienta).Využívá se především pro vyjádření zavislostí, jež nejsou asociací aznačí se přerušovanou šipkou od klienta k dodavateli. Navíc může ob-sahovat upřesnění formou stereotypu, např. «use», «friend», «bind»(obr. 4.4) nebo mezi třídou a její instancí «instantiate».

4.2.3 Další diagramy UML

Další diagramy UML si popíšeme již pouze stručně, případně na mo-delovém příkladu, kde se budeme snažit zachytit nejčastější a nejpou-žívanější notace specifické pro daný diagram.

Diagram objektů

Diagram objektů (instancí) ukazuje objekty a jejich propojení, včetněidentifikace význačných objektů v určitém čase. Hlavním účelem to-hoto pohledu bývá pomoc při pochopení složitějších vazeb mezi tří-dami (v diagramu tříd) prostřednictvím ilustrace na konkrétním pří-kladě několika instancí těchto tříd (obrázek 4.9). Protože reprezentujítaké statickou strukturu v konkrétním časovém okamžiku, lze diagra-my objektů používat i pro ověření koreknosti diagramu tříd, za jejížinstanci lze diagram objektů považovat.

Diagramy seskupení, komponent a zdrojů

Následující tři typy diagramů jsou většinou nově zavedeny či upravenyv UML verze 2 a jejich detailnější popis lze najít ve studijní literatuře(viz konec této kapitoly).

Diagram seskupení je vhodný především pro modelování rozsáh-diagram seskupenílých systémů a prezentaci vazeb mezi jeho podsystémy a dalšími mo-duly. Seskupení (angl. package) je prvek diagramu, který dokáže obalit


Pracanti s. r. o. : Firma

jmeno = "Tomas Povyseny"

VedouciIT : Zamestnanec

jmeno = "Jan Novak"

programator : Zamestnanec

pracovnik

vedouci

podrizenynadrizeny

Obrázek 4.9: Ukázka diagramu objektů (instancí)

a zapouzdřit libovolnou množinu entit, pro kterou to dává významovýsmysl, za účelem zpřehlednění vazeb mezi těmito množinami. Sesku-pení je značeno obdélníkem (s „ouškem“ pro popisek), který obepínávšechny zahrnované entity. Diagram seskupení je statického charakte-ru, protože reprezentuje seskupování v čase kompilace (překladu).

Diagram komponent ukazuje strukturu komponent systému a zá- diagram komponentvislosti mezi nimi. Komponenta je přístupná pouze prostřednictvímsvého rozhraní a je dána svými klasifikátory (specifikují komponentu)a artefakty (implementují komponentu). Tento typ diagramu je jižvelmi blízký samotné implementaci a bývá často využíván pro doku-mentaci nebo odhalení správného pořadí kompilace komponent sys-tému a zároveň tříd, které tuto komponentu implementují.

Diagram rozmístění zdrojů poskytuje pohled na fyzické rozmístění diagram zdrojůsystému, který je v tomto diagramu reprezentován pomocí uzlů pro-pojených komunikačními cestami. Uzel je v tomto grafu výpočetnímzdrojem rozděleným na procesor (schopný spouštět komponenty) azařízení (neumí spouštět komponenty).

Diagram případů použití

Při tvorbě specifikace a analýzy požadavků aplikace máme kromě slov-ního popisu detailů případů použití k dispozici také diagram případůpoužití, který graficky znázorňuje účastníky, případy použití, interakcea hranice systému.

Na obrázku 4.10 vidíme několik případů použití (ovály s popiskemuvnitř), které jsou využívány aktéry (Kupující, Čas). Entity aktérů isamotných případů použití lze generalizovat pro zvýšení přehlednostidiagramu podobně jako v případě diagramu tříd (např. v případě ak-terů Klient a ObchodniZastupce). Pomocí stereotypů «use» (impli-citní), «include» a «extend» lze upřesnit vztahy mezi samotnýmipřípady použití.

Diagram datových toků (angl. Data Flow Diagram) je hierarchickýmodel používaný při strukturované analýze a návrhu pro specifikaci

58 KAPITOLA 4. UML

«include»RozslatCeniky

ObjednejZajezd

Vypoc tiProvizi

ObchodniZastupce

Klient

Kupujici VyberZajezd

VytvorSouhrnProdeju

«extend»Cas

ObjednejZajezdAutobusem

ObjednejZajezdLetadlem

Obrázek 4.10: Diagram případu použití

octavia : Auto leveZadniKolo : Kolo

brzdi(ABS : bool)zastav()

Obrázek 4.11: Diagram spolupráce mezi dvěma jednoduchými objekty

chování systému. Na rozdíl od objektově orientovaného diagramu pří-padů použití je blíže návrhu, protože obsahuje i informace o datech.

Diagramy interakce

Základem vykonávání objektově orientovaného programu je zasílánízpráv. Zpráva je požadavek odesílajícího objektu o vykonání nějakéoperace v cílovém objektu (tzv. příjemce zprávy).

Interakční diagramy objektů popisují komunikační strukturuv době běhu modelovaného systému (tzv. dynamický popis) a jsoureprezentovány diagramem spolupráce (kolaborace) a diagramem sek-vence.

Diagram spolupráce popisuje objekty (instance tříd ze statickýchdiagram spoluprácepohledů) propojené pomocí posílání zpráv mezi těmito objekty (včetnějmen zpráv a jejich parametrů; viz obrázek 4.11, šipka směřuje ododesilatele k příjemci).

Druhým významným popisem dynamických vztahů v programu jediagram sekvence, který zdůrazňuje časovou posloupnost vztahů mezidiagram sekvenceobjekty. V některých případech jej lze využít pro detailnější popis(upřesnění) vybraného případu použití.

Příklad diagramu sekvence na obrázku 4.12 obsahuje tři objekty,z nichž vede směrem dolů úsečka (směr toku času) reprezentující linkuživota objektu. Aktivitu/převzetí toku řízení naznačujeme zesílenímlinky na podlouhlý obdélník. Šipky s návěštími mezi jednotlivými lin-kami života znázorňují synchronní či asynchronní komunikaci mezi pří-


RezervacniSystem AutorizaceKreditnichKaret

PotencialniKlient

Zadani platebnich udaju

Pozadavek na platebni udaje

Vyber konkretniho zajezdu

Over platebni kartu

Rezervace uskutecnena

Transakce overena

Obrázek 4.12: Diagram sekvence zjednodušeného rezervačního systému aověřením kreditních údajů

Novy/ vytvor

/ ulozitPracovne

Archivovat

Zobrazovat

Rozpracovano

/ ulozit/ archivovat

/ ulozit

Obrázek 4.13: Stavový diagram článku jednoduchého redakčního systému

slušnými objekty.

Stavový diagram

Stavový diagram (obrázek 4.13) se váže vždy na konkrétní třídu aukazuje stavy, do kterých mohou její instance vstupovat, a přechodymezi nimi. Při pokročilejším modelování tyto diagramy umožňují po-pisovat vnořené stavy (modularita), používané zprávy i s argumenty,souběžnost a synchronizaci.

Úlohy k procvičení:Pokuste se namodelovat pomocí jazyka UML vybraný diagram sa-motného UML. Jedná se o konstrukci tzv. metamodelu, kdy se sna-žíme popsat jazyk pomocí jej samotného. Tato vlastnost u libovol-ného jazyka zpravidla naznačuje jeho univerzálnost a flexibilitu.

60 KAPITOLA 4. UML

Klíč k řešení úlohInspirace pro řešení naleznete v knize [2].

4.3 Závěr

Tato kapitola zdaleka nepopsala všechny možnosti a syntaktické obratyjazyka UML, ale naznačila jeho hlavní aspekty a modelovací prvkypotřebné pro elementární používání při objektově orientované analýze,návrhu i programování.

Více informací najdete jak v mnoha knihách (i v češtině) speciali-zovaných na tento jazyk, tak například ve studijní opoře k předmětuIUS, kde je tento jazyk více provázán také s výkladem vybrané meto-dologie. Najdete zde také množství tipů a jednoduchých příkladů prokonstrukci objektově orientovaných modelů pomocí UML.

ZávěrUML je jednotný vizuální jazyk pro specifikaci, dokumentaci a mo-delování nejen při objektově orientované analýze a návrhu.UML diagramy jsou tvořeny stavebními bloky (prvky a vztahy mezinimi). Podle aspektu modelování pak diagramy dělíme na statické(modely struktury) a dynamické (modely chování).Hlavní pozornost je věnována diagramům objektů, tříd a vztahů mezinimi. V závěru jsou stručně probrány i ostatní diagramy.

Další zdrojeK tomuto tématu je i na českém knižním trhu k dispozici velké množ-ství kvalitních publikací (většinou překlady z anglických originálů).Prohloubení znalostí se zaměřením na vztah UML k objektově ori-entovaným jazykům naleznete v knize:• Jones, M. P.: Základy objektově orientovaného návrhu v UML,

Grada Publishing s.r.o., 2001, (překlad do češtiny Karel Voráček,Fundamentals of Object-Oriented Design in UML; Addison-Wesley,2000), ISBN 80-247-0210-X.

4.3. ZÁVĚR 61

Ještě přehledněji a srozumitelněji je napsána kniha s obrovskýmmnožstvím příkladů provázaných s celým procesem vývoje aplikací:• Arlow, J., Neustadt, I.: UML a unifikovaný proces vývoje aplikací,

Computer Press, Brno, 2003 (Addison-Wesley, 2002), ISBN 80-7226-947-X.Poslední dostupné texty vhodné pro rozšíření této kapitoly jsou:• Kočí, R., Křena, S.: Studijní opora předmětu Úvod do softwaro-

vého inženýrství (IUS), FIT VUT Brno, 2006.• Objektově orientované modelování systémů, učební text zaměřený

na jazyk UML 2.0, FIT VUT Brno, 2004.Dostupné na stránkách předmětu Úvod do softwarového inženýrství (IUS) (únor 2006).

62 KAPITOLA 4. UML

Kapitola 5

Vlastnosti objektověorientovaných jazyků

Tato kapitola se podrobněji zabývá pokročilejšími vlastnostmi přede-vším třídních jazyků založených na objektově orientovaném paradig-matu. Jsou však také diskutovány moderní techniky a vlastnosti pro-gramovacích jazyků, které jsou sice nejčastěji svázány s objektovýmparadigmatem, ale nejsou na něj bezpodminečně vázány. V druhé částise diskutuje otázka zpracování a překladu zdrojových textů objektověorientovaných jazyků.

Čas potřebný ke studiu: 5 hodin.

Cíle kapitolyCílem této kapitoly je poskytnout čtenáři povědomí i o pokročilejšíchtechnikách a principech používaných jak při programování v objek-tově orientovaných jazycích, tak při implementaci jejich překladačenebo interpretu.

Průvodce studiemOd studenta se předpokládá aktivní znalost konceptů objektovéorientace i všech důležitých pojmů z kapitoly 2. Dále požadujemei povědomí o principech konstrukce překladačů a interpretů jazykůnižších než jsou objektově orientované (především modulárních).

63

64 KAPITOLA 5. VLASTNOSTI OBJEKTOVĚ ORIENTOVANÝCH JAZYKŮ

Obsah5.1 Úvod . . . . . . . . . . . . . . . . . . . . . . . 65

5.2 Poznámka ke klasifikaci jazyků . . . . . . . 65

5.2.1 Pojmy . . . . . . . . . . . . . . . . . . . . . 65

5.2.2 Klasifikace jazyků . . . . . . . . . . . . . . 66

5.3 Vlastnosti třídních jazyků . . . . . . . . . . 68

5.3.1 Řízení toku programu . . . . . . . . . . . . 68

5.3.2 Jmenné prostory . . . . . . . . . . . . . . . 68

5.3.3 Modifikátory viditelnosti . . . . . . . . . . . 68

5.3.4 Přetěžování metod . . . . . . . . . . . . . . 69

5.3.5 Vícenásobná dědičnost . . . . . . . . . . . . 69

5.3.6 Rozhraní . . . . . . . . . . . . . . . . . . . 71

5.3.7 Výjimky . . . . . . . . . . . . . . . . . . . . 73

5.3.8 Šablony . . . . . . . . . . . . . . . . . . . . 74

5.3.9 Systémy s rolemi . . . . . . . . . . . . . . . 76

5.4 Poznámky k implementaci OOJ . . . . . . . 78

5.4.1 Manipulace se třídami . . . . . . . . . . . . 78

5.4.2 Virtuální stroj . . . . . . . . . . . . . . . . 80

5.4.3 Poznámka o návrhových vzorech . . . . . . 82

5.5 Zpracování - analýza, vyhodnocení, inter-pretace, překlad . . . . . . . . . . . . . . . . 83

5.5.1 Překladač . . . . . . . . . . . . . . . . . . . 83

5.5.2 Interpret . . . . . . . . . . . . . . . . . . . . 84

5.6 Závěr . . . . . . . . . . . . . . . . . . . . . . . 85

5.1. ÚVOD 65

Výklad

5.1 ÚvodNa úvod kapitoly si definujme obecnější pojmy nejen z oblasti progra-movacích jazyků, které budeme v textu používat.

Ortogonalita je obecně řečeno nezávislost jisté technologie na kon-textu použití a lze jí tedy využít i v jiném kontextu.

Definice 5.1.1 Konkrétně v textu o programovacích jazycích chá- Definice!peme ortogonalitu jako nezávislost vlastnosti jazyka na programovacímparadigmatu.

Například šablony a výjimky jako technologie jsou ortogonální vůčiobjektově orientovanému paradigmatu, z čehož plyne, že je lze uplatniti v jazycích, jež nejsou objektově orientované.

5.2 Poznámka ke klasifikaci jazykůV kontextu s OO jazyky se objevují některé nové nebo se více disku-tují dřívé méně časté typy jazyků. Nyní stručně shrneme a upřesnímenásledující kategorizaci (zdroj od zdroje se mírně liší). Vycházíme pře-devším ze striktnějšího přístupu k následujícím vlastnostem jazyků(viz [28]).Klasifikace jazyků podle několika významných kritérií (práce s typy): kritéria

1. podle určování typů při zápisu programu;

2. podle doby vytvoření vazby proměnné na typ;

3. podle způsobu typové kontroly;

4. podle důkladnosti typové kontroly.

Nejprve ještě projdeme několik základních pojmů, které budemedále potřebovat.

5.2.1 Pojmy

Datový typ popisuje reprezentaci, interpretaci a především strukturu datový typhodnot používaných algoritmy nebo objekty v paměti počítače. Typovýsystém pak typové informace využívá k ověření korektnosti počítačo-vých programů při jejich práci s daty.


Praktičtěji řečeno je typ většinou pojmenovaná doména mož-ných hodnot a vlastností/chování konkrétní entity jazyka (proměnné,funkce, metody, objektu).

Typová chyba je ohlášení chyby (při překladu nebo i při běhu),typová chybakterá označuje použití nepovolených/nekompatibilních/nevhodnýchtypů operandů při libovolné operaci.

Silně typová kontrola je takový typ kontroly, kdy jsou vždy dete-silná kontrolakovány všechny typové chyby, což vyžaduje schopnost určit typy všechoperandů (proměnných či výrazů v případě operací; parametrů v pří-padě funkcí či metod), ať již při kompilaci (staticky typované jazyky)nebo při běhu programu (dynamicky typované jazyky).

Nyní je popíšeme podrobněji spolu s příklady nejen objektověorientovaných jazyků.

5.2.2 Klasifikace jazyků

Podle určování typů při zápisu programu:

beztypové jazyky bez typů; v podstatě se jedná pouze o teoretickéa formální jazyky nebo jazyky s jediným univerzálním typem(např. ς-kalkul a λ-kalkul).

netypované proměnná nemá určen ve zdrojovém kódě typ a tuto in-formaci nemá programátor k dispozici (resp. jen pomocí explicit-ních dotazovacích funkcí na typ, pokud je vůbec jazyk/knihovnyjazyka nabízí); interpret/kompilátor zajišťuje implicitní typovékonverze automaticky. Např. BASIC, shell, PHP (předevšímstarší verze).

typované typ je určen ve zdrojovém programu u každé entity. Pro-měnná v těchto jazycích může mít typ určen explicitně (prová-záním typu a proměnné na úrovni zdrojového programu) neboodvozením (tzv. typová inference), kdy je výsledný typ výrazuodvozen z typů jeho operandů a samotných operací (vyhodno-cením typového výrazu nebo pomocí daných odvozovacích pra-videl).

Podle doby vytvoření vazby proměnné na typ:

staticky typované před během programu, tj. v době návrhu kompi-látoru, kompilace programu či zavádění programu; např. Delphi,C++, Java. Typování proměnné může být buď implicitní (např.podle jména proměnné), nebo explicitní (nejčastější).

5.2. POZNÁMKA KE KLASIFIKACI JAZYKŮ 67

dynamicky typované typ proměnné je určen až za běhu programu;např. jazyk Smalltalk. Všechny proměnné obsahují objekty, alekonkrétní typ záleží až na konkrétních přiřazených instancích(nejčastěji je typ závislý na třídě dané instance, ale třída nutněnemusí přesně korespondovat s typem, protože podstatný je sku-tečný typ objektu).

Podle způsobu typové kontroly:

statická typová kontrola kdy je většina typových kontrol prová-děna během překladu (stále však existují i u těchto jazyků kon-troly prováděné dynamicky za běhu; např. variantní záznamyv C/C++, jazyce Ada nebo Pascalu)

dynamická typová kontrola veškeré typové kontroly mohou býtprováděny až za běhu programu, což však ovlivňuje i výkonprogramů v těchto jazycích a často vyžadují běh na virtuál-ním stroji. Například jazyk Smalltalk, JavaScript, Python neboSELF.

Podle důkladnosti typové kontroly:

Tato kategorie rozděluje typované jazyky (netypované a beztypovév této kategorizaci neuvažuji):

• silně typované jazyky

téměř silně typované jazyky jako Modula-3, Java nebo Ada,u nichž neexistuje možnost jak implicitně způsobit typovouchybu/nekonzistenci s výjimkou explicitní typové konverze s vy-pnutou typovou kontrolou.

středně silně typované jazyky např. ML

absolutně silně typované jazyky, které jsou silně typované aneobsahují naprosto žádné implicitní konverze (některá variantaML nebo některé implementace Smalltalku či jazyka SELF).

• slabě typované jazyky jsou jazyky (např. Pascal, Fortran), kde jemožné i po úspěšné kompilaci dojít k typové chybě (např. va-riantní záznamy v Pascalu); dokonce velmi slabě typované jazykyjako C/C++ umožňují kromě volnější práce s variantním typem(union) i možnost nekontrolovat typy parametrů funkcí/metoda další typové prohřešky.


5.3 Vlastnosti třídních jazyků

Tato sekce se podrobněji věnuje některým specifičtějším vlastnostemtřídních jazyků. Nejprve je nastíněno řízení toku programu v hybridněobjektově orientovaných jazycích a poté je zmíněno několik důležitýchvlastností moderních OOJ, jež vhodně doplňují znalosti z kapitoly 2.

5.3.1 Řízení toku programu

Jak jsme si již uvedli, u hybridních OOJ se zachovávají vedle objekto-vých i klasické primitivní a strukturované typy. Protože ale tyto starétypy nerozumí zprávám, je nutno vedle mechanismu zasílání zpráv za-chovat i staré konstrukce ze strukturovaných a modulárních jazykůjako příkazy (větvení, cykly, atd.), výrazy a klíčová slova (např. ozna-čení prim. typů, řídící příkazy). Výhodou těchto jazyků je pozvolnějšípřechod z modulárních jazyků na objektově orientované (uživatel nenínucen hned začít myslet plně objektově), ovšem s rizikem, že se můžeuživatel naučit špatnému objektovému myšlení. Pro podporu pocho-pení objektového paradigmatu je proto lepší si alespoň vyzkoušet ně-který čistě objektový jazyk. Další nevýhodou tohoto přístupu je kom-plikovanější syntaxe i sémantika (například různý způsob práce s pro-měnnými potažmo hodnotami, jež jsou buď primitivního typu, neboobjektového).

5.3.2 Jmenné prostory

Jmenný prostor (angl. namespace) je z programátorského hlediskakontejner pro identifikátory (či jiné entity jazyka). V tomto prostoruplatí pravidlo, že uvnitř se nevyskytují žádné dva stejné identifikátory(pokud bereme v úvahu jejich plnou kvalifikaci). V UML lze jmennýprostor modelovat pomocí entity seskupení. Důvodem zavádění jmen-ných prostorů do jazyků je zabránění kolizí jmen v rozsáhlých zdrojo-vých textech, kde se běžně využívají množiny tříd více autorů. Tatojazyková vlastnost nemá, podobně jako přetěžování metod a operá-torů, nezbytnou vazbu na objektově orientované jazyky, ale je v nichs výhodou velmi často využívána.

5.3.3 Modifikátory viditelnosti

Modifikátor viditelnosti je mechanismus přítomný v mnoha dnešníchOOJ, který má za úkol měnit možnost přístupu k různým entitám ja-zyka, a tak podrobněji konfigurovat koncept zapouzdření. Takto ovliv-ňovanými entitami bývají nejčastěji atributy a metody, dále vlastnosti

5.3. VLASTNOSTI TŘÍDNÍCH JAZYKŮ 69

a někdy i dědičnost (pro systematické omezení viditelnosti všech entitv nové třídě). Již v jazyce UML (viz kapitola 4) jsme se mohli setkatse třemi základními modifikátory:

• soukromý (angl. private) — atributy či metody jsou přístupnépouze z metod stejné třídy

• chráněný (angl. protected) — atributy či metody jsou dostupnépouze z metod střejné třídy a tříd odděděných

• veřejný (angl. public) — atributy či metody jsou dostupné od-kudkoliv (z libovolné metody)

V některých jazycích k nim mohou přibýt i další specifičtější mo-difikátory. Například v případě jazyka se jmennými prostory má smysluvažovat modifikátor, který zajistí veřejnou viditelnost pouze uvnitřdomovského jmenného prostoru (např. internal v C#). Za účelemefektivnější implementace může být výhodné mít možnost přistupo-vat k soukromým entitám v případě tzv. spřátelených tříd, které jsouv blízkém závislostním vztahu (např. friend v C++).

Jiné jazyky zase považují porušování zapouzdření za zavrženíhodnýnešvar a napevno viditelnost určují (např. soukromá viditelnost atri-butů a veřejná viditelnost všech metod v jazyce Smalltalk).

5.3.4 Přetěžování metod

Přetěžování metod (angl. method overloading) je vlastnost (opět nenídoménou pouze objektově orientovaných jazyků) umožňující definovatve třídě (respektive v protokolu objektu) více metod se stejným jmé-nem. Jediným požadavkem bývá, aby se metody odlišovali v typechnebo v počtu parametrů.

Kromě přetěžování metod se někdy umožňuje přetěžovat i operáto-ry (unární i binární), což ovšem nemusí být za všech okolností vhodné.

Úlohy k procvičení:Zamyslete se nad tím, proč nestačí, aby se signatura přetěžovanýchmetod lišila pouze v návratovém typu. Dále najděte příklad jazyka,který podporuje přetěžování funkcí a není objektově orientovaný.

5.3.5 Vícenásobná dědičnost

V definici předků dané třídy může být uvedená i více jak jedna třída.Typickým reprezentantem je jazyk C++, dále třeba CLOS. Tento typdědičnosti má však bohužel více nevýhod než výhod, které v následu-jící sekci probereme detailněji:


• opravdu oprávněné a správné použití je velmi ojedinělé (častopouze svádí k chybám v návrhu);

• efektivní implementace patří mezi pokročilejší problémy návrhuOOJ.

Příklad 5.3.1 Vícenásobná dědičnost, demonstrace konfliktů jmen.

class A isint d;float dA;float f(int);

endOfClass

class B isint d;float dB;float f(int);int g(float);

endOfClass

class C inheritedfrom A, B is

int dC;int h(int);

endOfClass

V příkladu jsou viditelné následující problémy, které musí překla-problémydač OOJ s vícenásobnou dědičností řešit:

1. rodičovské třídy mohou obsahovat členy stejného jména i typu;

2. nebo jen stejného jména a různého typu;

3. pořadí volání konstruktorů (tzv. pořadí inicializace), případnědestruktorů;

4. uložení objektu třídy C v paměti tak, aby jej bylo možno využítkdekoli je očekáván objekt třídy A, B nebo C (např. v rámcivyžadované dědičnosti).

Návrhy řešení některých problémů vícenásobné dědičnosti:návrhy řešení

ad 1) Kolize metod stejného jména i typu v nové třídě lze řešit třemizpůsoby: (a) sémantickými kontrolami zakázat tuto možnost již přikompilaci zdrojového kódu, (b) dožadovat se v případě kolize upřesně-ní, ve které třídě volanou metodu hledat (tzv. kvalifikace metody) anebo (c) vyžadovat povinnou reimplementaci, což má ovšem svá úskalí(např. při využití na místě, kde je očekáván objekt rodičovské třídy).ad 2) Kolize metod se stejným jménem ale různým návratovým typemu nové třídy, kde se buď (a) tento případ zcela zakáže podobně jako


v předchozím případě, nebo (b) se povolí existence obou metod ovšempouze v případě, že daný jazyk umožňuje přetěžování, což kromě pře-kladu zvyšuje i režii u pomocných rutin za běhu programu.

ad 1 a 2) Atributy stejného jména i typu jsou řešeny analogicky k pro-blému s metodami. Pouze v případě stejně pojmenovaných atributůjiných typů se zatím nepodařilo úspěšně implementovat přetěžování,takže se tato kombinace zpravidla zakazuje.

ad 3) Problém s inicializací se týká pořadí volání konstruktorů (metodysloužící pro inicializaci objektu při jeho vytváření), jež jsou automa-ticky spouštěny nejen z třídy daného objektu, ale většinou i z rodi-čovských tříd. První možností je využití pořadí zápisu tříd ve zdrojo-vém textu, v jakém byly v seznamu rodičovských tříd instanciovanétřídy uvedeny. Toto řešení většinou využívá algoritmu prohledávánído hloubky v hierarchii dědičnosti od dané třídy směrem k předkůma vrací první nalezenou shodu, čímž se stává deterministickým i v pří-padě více cest k některému z předků. Přesnější stanovení pořadí ialgoritmus hledání jsou specifické pro jednotlivé OOJ s vícenásobnoudědičností. Dalším způsobem je ignorování zápisu ve zdrojovém textu,ale využití uživatelem definovaného pořadí inicializace, které ovšemnení dodatečně kontrolováno na případné uváznutí (angl. deadlock) činesprávné pořadí.

ad 4) Ani pro způsob ukládání objektů v OOJ s vícenásobnou dědič-ností neexistuje jedno univerzální a obecné řešení, které navíc většinousilně závisí na vlastnostech daného jazyka. Typicky lze ukládat členyjednotlivých tříd v objektu do bloků podle tříd a v případě kolize jmenvytvořit duplikát daného člena v obou příslušných blocích. Při očeká-vání rodičovské struktury u takovéhoto objektu je však třeba zajistitsynchronizaci obsahů duplikovaných atributů.

5.3.6 Rozhraní

Výhodou vícenásobné dědičnosti oproti jednoduché je možnost sdí- motivacelení protokolu napříč hierarchií dědičnosti, tj. i u tříd z různých větvístromu dědičnosti lze syntakticky zaručit existenci patřičného podpro-tokolu. Hlavní nevýhodou je však problém s kolizí různých implemen-tací pro stejně pojmenované metody (případně i atributy). Zachová-ním popsané výhody a vyloučením nevýhod dostáváme mechanismusrozhraní (angl. interface), který je schopen s jistými omezeními zcelanahradit vícenásobnou dědičnost.

Přestože je princip rozhraní znám již delší dobu a jeho implemen- zástupcitace je mnohem jednodušší než u vícenásobné dědičnosti, tak se stávápopulární až v moderních OOJ s jednoduchou dědičností jako Java


a C#. Rozhraní však není omezeno pouze na objektově orientovanéjazyky (např. funkcionální jazyk Haskell).

Definice 5.3.1 Rozhraní je schéma, které deklaruje seznam metodDefinice!(jména, parametry, návratové typy). Použití rozhraní na jistou třídupak vynucuje implementaci všech metod uvedených v rozhraní. I v pří-padě jednoduché dědičnosti lze každé třídě uvést několik rozhraní.

Zjednodušeně lze na rozhraní pohlížet jako na speciální třídu, kteráobsahuje pouze abstraktní metody (tj. metody bez implementace1).Mechanismus rozhraní lze využívat i v ostatních programovacích pa-radigmatech.

Příklad 5.3.2 Definice a použití rozhraní.

interface Comparable definesbool isEqual(class Comparable, class Comparable);

endOfInterfaceinterface Orderable extends Comparable defines

bool lessThan(class Orderable, class Orderable);endOfInterfaceinterface Printable defines

void print(class Printable);endOfInterface

class IntegerNumber implementing Orderable, Printable is...bool isEqual(class Comparable, class Comparable);bool lessThan(class Orderable, class Orderable);void print(class Printable);...

endOfClassclass Square implementing Printable is

...void print(class Printable);...

endOfClass

Nyní můžeme vytvořit funkci, jež by řadila pole libovolných objektů,u nichž by byl jediný požadavek—jejich třída musí implementovat roz-hraní Orderable.

sort(class Orderable[])

Rozhraní tedy povoluje existenci tzv. generického polymorfismu.To je odlišný přístup než například v případě tradičního přetěžováníoperátorů, které je definováno pro každý typ zvlášť. Naše generickéřešení tak bude použitelné i pro typy/třídy/objekty, které ještě v doběimplementace tohoto řešení neexistovaly.

I když je implementace rozhraní jednodušší než v případě vícená-implementace1Z toho důvodu se většinou nepovolují v rozhraních definovat instanční pro-

měnné.


sobné dědičnosti, přesto je v případě kombinace s jednoduchou dědič-ností nutno zvolit nejvhodnější implementaci:

a) vázání přes jméno rozhraní (nikoliv přes adresu; nutno provádětza běhu a často s podporou virtuálního stroje; např. Java, kteráobsahuje v bytekódu (angl. bytecode) plnou jmennou kvalifikacirozhraní);

b) několik tabulek virtuálních metod (pořadí je dáno zápisem roz-hraní ve zdrojovém textu);

c) metody get/set (vázání přes jméno pro kompilované jazyky;metody get a set slouží pro získání adres kódu metody zadanéhojména).

Nevýhoda oproti vícenásobné dědičnosti—nelze zajistit sdílení im- nevýhodaplementace jistého chování napříč hierarchií dědičnosti, což lze ovšemobcházet pomocí pokročilých návrhových vzorů (viz [10]).

OtázkaMějme rozhraní Comparable z předchozího příkladu, které vyžadujeimplementaci metody (zprávy) isEqual, tzv. požadovaná metoda.Uvažujme ale případ, kdy chceme sdílet v rámci tohoto rozhraníi tzv. odvozené metody, jejichž výpočet je založen na požadova-ných metodách, ale jinak je univerzálně platný. Například zprávaisNotEqual, jež lze implementovat pouhou logickou negací výsledkumetody isEqual. Nyní ovšem nastává problém, protože definice roz-hraní neumožňuje, aby rozhraní obsahovalo implementaci. Pokustese navrhnout funkční řešení tohoto problému.

Klíč k řešení úlohProstudujte v [10] vhodné návrové vzory pro vyřešení tohoto problé-mu.

5.3.7 Výjimky

Moderní způsob ošetřování chybových a neočekávaných stavů vyko-návaného programu je využití výjimek (angl. Exception), což je me-chanismus, který popisuje způsob šíření informace o chybě, způsobzastavení/přeskočení výpočtu a umožňuje provést ošetření chyby ažza samotným algoritmem a tím zlepšit čitelnost kódu i samotného al-goritmu. V neposlední řadě umožňuje také spouštění finalizační sekce,jejíž provedení je garantováno i v případě vyvolání výjimky (tj. dekla-rativně označená sekce, která nesmí být vynechána při přeskakováníchybné nebo chybou ovlivněné části programu).


Příklad 5.3.3 Nejčastější programová struktura try-catch-finally propráci s výjimkami nejen v OOJ.

class FileException inherits from Exception is... // definice nové třídy výjimek

endOfClass...void g()

if ((fIn = fopen(file, "r")) == NULL)e = FileException(file, "r"); // vytvoření objektu výjimkye.where("module.fun"); // inicializace výjimkyrise(e); // vyvolá výjimku

endifend;...try

... g(); ... // blok sledovaný na výjimkycatch(e)

if (e is FileException)... // zpracování/ošetření výjimky

finally... // nevynechatelný kód, finalizační sekce

endTryCatchFinally

Při vyvolání výjimky uvnitř try-bloku (příkazem či zprávou risenebo v některých jazycích příkazem či zprávou throw) je provedenskok na začátek catch-bloku a na jeho formální parametr je navázánvzniklý objekt výjimky. V ošetřovacím kódu (catch-blok) je pak vět-šinou potřeba zjistit, jaké třídy výjimka je, abychom věděli, jak s nínaložit.2

Jak již bylo zmíněno v úplném úvodu kapitoly, tak výjimky jsouortogonální technikou vůči OOP, kterou lze využívat i v strukturova-ných/modulárních či deklarativních jazycích (např. Haskell).

5.3.8 Šablony

Šablony mohou být implementovány v zásadě třemi způsoby:

1. staticky (šablona je zpracovávána a využívána pouze při kompi-laci zdrojového kódu; v podstatě se jedná o velmi sofistikovanérozšíření preprocesoru jazyka, např. maďarská notace v C++)

2. dynamicky (v případě hybridních jazyků nejčastěji pomocí vir-tuálních funkcí resp. metod, což vyžaduje dodatečnou režii zaběhu programu)

3. ad hoc (v jazyku předem a napevno definované přetěžovánímoperátorů pro omezený počet typů, např. Pascal a jeho operátor+ pro sčítání číselných typů i konkatenaci řetězců)

2Ke zjištění typu výjimky lze samozřejmě kromě reflexe využít i uživatelskéčleny struktury, která výjimku reprezentuje.


Příklad 5.3.4 Ve staticky typovaných jazycích často potřebujemebudovat homogenní strukturovaný datový typ. Problémem je, pokuddanou strukturu potřebujeme pro předem neznámý výčet typů jehoprvků nebo je tento výčet nemalý. Bez šablon bychom museli provéstdefinici strukturovaného typu pro každý typ jeho prvků zvlášť (a tonemluvě o typech, které teprve vzniknou někdy v budoucnu).

Cvičení: Navrhněte třídu reprezentující abstraktní datový typBinaryTree pro binární strom. Uvažujte požadavek na homogenitujeho prvků. Jakým způsobem lze zadání implementovat v OOJ bezšablon a se šablonami?

Definice 5.3.2 Šablona je mechanismus, který umožňuje parametri- Definice!zaci definic datových typů (a potažmo i tříd). V definici nového šab-lonového typu potom daný parametr využíváme jako proměnnou, kteráobsahuje identifikaci jiného typu. Šablony mohou obsahovat i více pa-rametrů.

Šablonový typ je nutné před použitím ve zdrojovém textu instan- použitíciovat. Tj. dosadit za parametry konkrétní datové typy. Až z konkre-tizovaného šablonového typu lze vytvářet proměnné daného typu. Vý-hoda šablonového typu je, že může být využit i jako parametr funkcía metod a tím zvýšit flexibilnost těchto funkcí v době překladu (nikolivšak v době běhu, kdy již jazyky vyžadující šablony potřebují mít vevšech typech jasno).

Cvičení - pokračování: Objektově orientované řešení bez šablon vestaticky typovaných jazycích

Pro uzly bychom vytvořili abstraktní třídu TreeNode, která by oba- výhody, nevýhodylovala prvky stromu. Třída pro samotný strom Tree by pak k manipu-laci s těmito uzly využívala abstraktní operace (protokol definovanýabstraktní třídou pro uzly TreeNode). Hlavní nevýhodou tohoto ře-šení je jeho nízká flexibilita a nutnost nešikovného zapouzdření prvkůabstraktní třídou. Proto je využítí šablon v takových případě pohodl-nější a výhodnější především pro spravovatelnost zdrojového kódu aznovupoužitelnost (případně rozšiřitelnost).


Řešený příkladZadání: Vytvořte skeleton pro třídu pro abstraktní datový typ binárnístrom s homogenním prvky s využitím OOJ se šablonami. Příklad jeřešen v C++.

Řešení: T je v době psaní kódu neznámý typ; v době překladu však jižznámý je (případně až v několikátém průchodu zdrojovým kódem).

template<class T> class Node{

public:Node(Node<T> *the_parent = NULL);T item;int number_of_items;Node<T> *parent;Node<T> *left_child;Node<T> *right_child;

};

template<class T> class BTree{

public:BTree();~BTree();void Insert(T item);...

private:bool r, l;int node_count;Node<T> *root; // samotná datová struktura stromuvoid Insert(T item, Node<T> *tree, Node<T> *parent);void List_PreOrder(Node<T> *tree, Node<T> *parent);...

};

5.3.9 Systémy s rolemi

Motivací k těmto systémům jsou případy, kdy objekt přetrvává v sys-motivacetému dlouhou dobu a postupně se vyvíjí a je potřeba tomu přizpů-sobovat i schopnosti (protokol) tohoto objektu. Pro konkrétní použitítedy objekt může přebírat konkrétní roli. Objekt může během svéhoživota v systému s rolemi vystupovat pod různými rolemi, které můžepostupně nabývat nebo pozbývat (za běhu systému, tj. za života ob-jektu).

Definice 5.3.3 Objekt s více typy je objekt, který může mít v jedenDefinice!okamžik více typů. Původ tohoto pojmu je v objektově orientovanýchdatabázích, kde pak hovoříme o rolích objektu.


Příklad 5.3.5 Systém s rolemi - motivace.class Person is

...endOfClass

class Student inherited from Person is...

endOfClass

class Boarder inherited from Person is...

endOfClass

V roce 1999 v systému s rolemi mohl vzniknout objekt Pavel, ježvystupuje pod rolí Student. O rok později si Pavel zaplatil stravovánív menze a přibyla mu další role Strávník (angl. Boarder). Za další4 roky Pavel ukončil studium a byla mu odebrána role Student, aleprotože menza prodává obědy i nestudentům, tak mu role Strávníkazůstala.

S vícenásobnou dědičností bychom nevystačili ze dvou důvodů:

1. je možné velké množství kombinací, které by se velmi těžko udr-žovalo;

2. nelze předpovídat jaké další role bude nutné dotvořit v průběhuprovozování samotného systému.

Systémy s rolemi používají většinou perzistentní objekty, což jsou použitíobjekty, které přežívají nezávisle na běhu nebo ukončení obsluhujícíaplikace.

Systémy s rolemi jsou většinou interpretované systémy, kde je po-třeba provádět asociaci objektu a role za běhu (přidávání, odebíránírolí objektu). Například objektově orientované databáze nebo inter-pretované systém s dlouho-žijícími objekty.

Perzistentní objekty

Objekt či instanci označujeme za perzistentní, pokud přežívá rámec perzistentní objektaplikace (čas kdy aplikace běží) a při dalším spuštění aplikace je tentýžobjekt opět k dispozici v přesně stejném stavu jako měl při poslednímukončení aplikace.

Perzistence ale není jenom snímek objektové paměti (tzv. sna-pshot). Explicitní ukládání a načítání dat pro rekonstrukci objektůtaké nepovažujeme za perzistenci. Programátor by měl pouze deklara-tivně (např. pomocí klíčových slov) určit, které objekty se mají chovatjako perzistentní a které nikoliv (tzv. dynamické nebo krátkodobé).

Krátce si popišme dva možné přístupy k implementaciperzistentních objektů: implementace


a) ukládát pouze stav objektu (hodnoty atributů) – metody ob-jektu musí být dosažitelné jiným způsobem (například přes od-kaz na třídu nebo role objektu, kde třídy/role jsou uloženy oddě-leně od objektů); z teoretického pohledu se však nejedná o plno-hodnotnou perzistenci, jelikož lze pohodlně zajistit knihovnamipro ukládání a načítání stavu objektů;

b) ukládat stav objektu i jeho metody (případně třídu objektu)– protože na kompilovaných systémech je třeba v tomto pří-padě řešit mnoho problémů (nutnost funkcí pro práci s kódemjako s daty, které bývají značně závislé na platformě), provádíse pouze překlad do mezikódu, jenž je následně interpretovánvirtuálním strojem.

5.4 Poznámky k implementaci OOJ

Při zamýšlení se nad implementací objektového jazyka je třeba brátv úvahu několik zásadních omezení nejčastěji používané von Neuman-novy architektury počítačů, kdy nemáme k dispozici nic jako čistě ob-jektovou paměť nebo mechanismus zasílání a směrování zpráv. Značnémnožství moderních OOJ řeší tyto nevýhody vytvořením tzv. virtu-álního stroje, který vytváří pro jazyk interpretační nebo pseudopře-kladové prostředí obsahující objektovou paměť i snadnější práci sezprávami. Tomuto tématu se podrobněji věnuje sekce 5.4.2.

5.4.1 Manipulace se třídami

Pro ukládání atributů (datové části) objektu se v případě hybridníhoobjektového přístupu jednoznačně nabízí využití datových struktur,jak je známe ze strukturovaných jazyků. Mírným problémem je u to-hoto řešení nedostatečná variabilita takovéto struktury, která je proukládání některých objektů nezbytná.

Zásadní problémy, které je nutno řešit:

• ukládání metod

• dědičnost

• přístup k atributům v metodách

• instanční a třídní proměnné (atributy), instanční a třídní metody

Čistě objektové jazyky se těmto problémům vyhýbají díky běhu vevirtuálním stroji, o kterém se více dozvíte v sekci 5.4.2.

5.4. POZNÁMKY K IMPLEMENTACI OOJ 79

Problém uložení v paměti se týká především metod, které majívždy různou délku (počet instrukcí po překladu). Do struktury, kteráv praxi reprezentuje objekt, se tak často vkládají pouze ukazatele nakód metod, který se nachází jinde v paměti.

Při podrobnějším prostudování následujícího příkladu zdrojovéhotextu (př. 5.4.1) vidíme, že metoda f1 je statická, a tudíž nemá pří-stup k instančním proměnným ani ostatním nestatickým metodám.Metody f2 a f3 jsou virtuální a implementace jejich uložení v pamětia následná invokace si bude žádat zvláštní pozornost, protože v doběpřekladu nemůžeme zaručit, že se skutečně budou volat přímo tytometody, či jejich redefinice v některém z potomků třídy A.

Příklad 5.4.1 Zdrojový text reprezentuje dvě třídy A a B. Na obrázku5.1 pak vidíme grafické znázornění instance třídy B v klasické paměti.

class A{

public:int a, bstatic int f1(int);float c;virtual float f2(int, float);

private:int d;virtual int f3(int, int);float g(float);

}

Problém s dědičností je patrný na následující třídě B, která dědíz předchozí třídy A. Její virtuální metoda f2 je redefinována a v případějejího volání s využitím polymorfismu musíme zajistit exekuci kódusprávné metody—té novější v případě objektu třídy B.

class B : A // B dědí z třídy A{

public:int i;static int g1(int);float j;virtual float f2(int, float);

private:virtual int g2(int, int);

}

B objB = new B();objB.f2(0, 0.0) // příklad invokace f2 v objB

Na obrázku 5.1 vidíme nastíněno již plně vyhovující řešení, kterésplňuje všechny nastíněné požadavky:

• Statické metody a proměnné (neboli třídní metody a proměnné)nejsou uloženy v objektu ani VMT (u nich neexistuje v takovétoimplementaci žádný polymorfismus).


int j

int i

int d

int c

int b

int a

Pointer to VMT

Class ID

int g2(int, int)

int f3(int, int)

float f2(int, float)

Pointer to superVMT

int f3(int, int)

float f2(int, float)

Pointer to superVMT

super VMT

VMT

Obrázek 5.1: Realizace uložení objektu třídy B pomocí tabulek virtuálníchmetod (VMT)

• Instance třídy B má dostupné jak svoje metody, tak metodyvšech předků (postupným procházením propojených VMT). Po-znamenejme, že i VMT je implementována jako dynamickástruktura a tedy obsahuje pouze reference na skutečný kód da-ných metod.

Úlohy k procvičení:Zamyslete se nad možnostmi optimalizace tabulky virtuálních metod.

5.4.2 Virtuální stroj

Virtuální stroj je speciální softwarová vrstva, jejíž primárním účelemje odstínit pro běžící aplikaci hardwarová specifika počítače, na němžje vykonávána. Do toho zahrnujeme i proces samotného vykonáváníkódu, díky čemuž je dosaženo naprosté nezávislosti na konkrétní plat-formě.

Virtuální stroje se v přístupu k vykonávání kódu mohou značněvykonávání kódulišit. V zásadě volí jeden z následujících přístupů

• přímá interpretace kódu ze syntaktického stromu zdrojovéhokódu (např. jazyk )

• kompilace do mezikódu a jeho následná přímá interpretace(Smalltalk-80)

• kompilace do mezikódu, jeho následný překlad to nativního stro-jového kódu a vykonání (SELF, Java)

Jako mezikód se ve většině případů využívá tzv. bytekód (angl. by-bytekódtecode), což je binární forma mezikódu s členěním po bytech. Tento

5.4. POZNÁMKY K IMPLEMENTACI OOJ 81

bytekód je nezávislý na platformě, oproti přímé interpretaci ze zdrojo-vých kódů je rychlejší a nevyžaduje překladač jako součást virtuálníhostroje. Většinou se jedná o rozšířený zásobníkový kód a tabulka jehooperačních kódů bývá silně optimalizována. Bytekód nebývá přímozávislý na jednom programovacím jazyce, ale obecně platí, že pro sta-ticky typované programovací jazyky je komplikovanější, protože musíumět pracovat i s typovou informací.

Kvůli snaze zvýšit rychlost interpretace bytekódu se začal prová-dět jeho překlad do nativního strojového kódu konkrétní hostitelsképlatformy. Při tom se ve většině případů optimalizují pouze kritickámísta, ve kterých program tráví nejvíce času. Díky tomu, že se tytooptimalizace provádí v čase běhu programu, bývají cílenější a účinnějšínež optimalizace prováděné při statickém překladu. Daní za často řá-dově vyšší rychlost, než kterou poskytuje interpretace bytekódu, jepodstatně komplikovanější a hůře přenositelný virtuální stroj.

Zásadní roli hrají virtuální stroje při práci s pamětí. U objektově práce s pamětíorientovaných jazyků se nechápe paměť jako sekvenční prostor proukládání dat, ale přímo jako množina objektů. Díky tomu většina mo-derních objektově orientovaných programovacích jazyků poskytuje au-tomatickou správu paměti. Tu zajišťuje tzv. garbage collector 3 (GC), garbage collectorkterý automaticky vyhledává a ruší nepotřebné již neodkazované ob-jekty. Implementace kvalitního GC je netriviální záležitost a většinouse v něm vhodně kombinuje několik implementačních strategií. Au-tomatická správa paměti přirozeně vyžaduje jistou režii. Protože nadní programátor nemá plnou kontrolu, může v krajních případech véstaž k těžko odstranitelným výkonnostním problémům. Proto některéjazyky dovolují manuální a automatickou správu paměti kombinovat(např. ObjectiveC).

Některé jazyky (např. Smalltalk, SELF) dovolují používat tzv. ob-razy objektové paměti (angl. image, snapshot). Při spuštění programu obrazy objektové pa-

mětipak nedochází k postupné inicializaci objetků podle pokynů programu,ale je obnoven naposledy uložený stav. Tento přístup má celou řaduvýhod (např. velice rychlý start aplikací) a pro objektové systémy jetato architektura paměti přirozená, nicméně v praxi se s ní zatím nelzesetkat příliš často. Místo pouhého kódu programu je totiž nutné dis-tribuovat celý obraz objektové paměti, který je objemnější. U obrazůse rovněž lze setkat s problematičtější modularitou aplikací.

Hlavní nevýhodou virtuálních strojů je podstatně vyšší režie, než nevýhody virtuálníhostrojev případě nativních programů. Rovněž větší odstup od prostředků hos-

titelského systému může být v některých případech velmi svazující.Nicméně tato architektura se díky svým nesporným výhodám stále

3Český ekvivalent termínu „garbage collector“ se zatím neustálil.


více prosazuje a to i případech, kdy výsledné programy nejsou vytvá-řeny s ohledem na použití na více hardwarových platformách.

5.4.3 Poznámka o návrhových vzorech

Návrhové vzory (angl. design patterns) jsou obecná znovupoužitelnánávrhový vzorřešení často se vyskytujících problémů v programovém návrhu. Jednáse o popis postupu nebo šablonu, pomocí které pohodlně daný problémsprávně a efektivně vyřešíme. Objektově orientované návrhové vzory setypicky týkají vztahů a interakcí mezi třídami a objekty, aniž bychompřímo specifikovali konkrétní třídy a objekty naší konkrétní aplikace.Jedná se tedy o postupy s vysokou mírou abstrakce a z toho plynoucíflexibilitou a znovupoužitelností.

Definice 5.4.1 Návrhový vzor systematicky nazývá, vysvětluje a vy-Definice!hodnucuje důležitý a v objektově orientovaných systémech se opakujícínávrh.

Návrhové vzory lze zevrubně rozdělit takto:

1. Vytvářecí (instanciační, tvořivé) vzory — nepřímou cestou pronás vytváří objekty, aniž bychom je museli vytvářet přímo, aposkytují nám tak větší flexibilitu programů (např. Prototyp,Jedináček)

2. Strukturální vzory — napomáhají při shlukování objektů do vět-ších celků, jako například komplexní uživatelské rozhraní apod.(např. Dekorátor, Adaptér, Kontejner, Proxy)

3. Vzory chování — pomáhají při definici komunikace mezi objektyv systému a toku řízení ve složitějších programech (např. Pozo-rovatel, Návštěvník)

Nejjednodušší a v praxi nejběžnější návrhové vzory (podle [10])jsou Abstraktní továrna, Adaptér, Dekorátor, Pozorovatel, Skladba,Strategie, Šablonová metoda a Tovární metoda.

Nyní si krátce rozepíšeme jeden ze základních jednoduchých návr-hových vzorů z kategorie vytvářecích.

Jedináček

Jedináček (angl. singleton) je návrhový vzor, který omezuje možnostivytvářet z třídy více jak jednu instanci. Existuje mnoho případů, kdyprogramátor potřebuje zajistit, že od dané třídy vznikne nejvýše jedna

5.5. ZPRACOVÁNÍ - ANALÝZA, VYHODNOCENÍ, INTERPRETACE, PŘEKLAD 83

instance, například přístupový bod k databázi nebo instance metatřídy(tedy třída). Jedináček bývá nejčastěji implementován pomocí veřej-né statické metody, soukromé statické proměnné a zakázáním voláníkonstruktoru z ostatních tříd (nastavení viditelnosti konstruktoru nasoukromou).

5.5 Zpracování - analýza, vyhodnocení, in-terpretace, překlad

Při zpracovávání objektově orientovaného jazyka máme tři možnosti:

1. Provést překlad zdrojového textu do samostatného modulu,který obsahuje přímo instrukce daného procesoru (případně takésplňuje požadavky operačního systému). Výsledkem bývá tzv.nativní aplikace, podobná těm, které dostáváme jako výsledekpřekladu většiny strukturovaných a modulárních jazyků.

2. V případě čistých objektově orientovaných jazyků potřebujememít pro objektový program k dispozici paměť, která se chovájako objektová, a také instrukce pro zasílání zpráv. Tyto po-žadavky však nesplňuje dnešní von Neumannovská architekturapočítačů, tak je nutno si vytvořit vrstvu mezi procesorem (pří-padně operačním systémem) a naším objektovým programem.Takovéto mezivrstvě říkáme virtuální stroj, který je podrobnějipopsán v sekci 5.4.2 na straně 80. V tomto případě pak překladačprovádí transformaci zdrojového textu na kód, kterému rozumíonen virtuální stroj, jenž tento kód dokáže interpretovat.

3. Poslední možností je čistá interpretace zdrojového kódu bez pře-kladu, která je však neefektivní (pomalá) a využívá se spíše vý-jimečně.

5.5.1 Překladač

U třídně založených OOJ se většinou praktikuje ukládání popisu každétřídy do zvláštního souboru4. Již díky tomuto přístupu je překladačOOJ minimálně tak složitý jako překladač modulárních jazyků, kdy

4 Výjimku ve způsobu uchovávání zdrojových textů tvoří některé OOJ vyu-žívající virtuální stroj, které mají vlastní grafické vývojové prostředí, které námposkytuje různé nástroje od prohlížeče hierarchie tříd, až po návrh grafickéhouživatelského rozhraní vaší aplikace (např. SELF, Smalltalk). Samotné, do kóduvirtuálního stroje přeložené, metody bývají v tomto případě součástí sdílené ob-jektové paměti. Někdy se z praktických důvodů ukládá do formátovaného souborui textová reprezentace tříd a metod (kvůli přenositelnosti definicí mezi různými


musí být schopen vytvořit graf závislosti pro překlad jednotlivých třída poté je ještě lineárně uspořádat, což se nemusí vždy podařit bě-hem jednoho průchodu. Další nezbytností je využívání lokálních tabu-lek symbolů během syntaktické analýzy, například pro atributy třídy.Náročným úkolem je i práce se jmennými prostory a různými mo-difikátory (např. modifikátor viditelnosti internal v C# pro určeníviditelnosti dané entity pouze v rámci domovského jmenného prosto-ru).

Z hlediska lexikální a syntaktické analýzy OOJ nevyžadují žádnéspeciální přístupy nebo náročnější algoritmy než jazyky strukturovanénebo modulární. Ovšem jak již víme, tak oba typy analýzy jsou velmiúzce spjaty s analýzou sémantickou, která je v OOJ o poznání slo-žitější. Často je potřeba provádět v rámci sémantické analýzy i syn-taktickou, takže je velmi relevantní efektivita lexikální a předevšímsyntaktické analýzy, kterou bychom měli v rozumné míře požadovat.

Sémantická analýza

Tato část překladu patří u OOJ mezi stěžejní. Uvádíme příklady sé-mantických kontrol a analýz, které však nemusejí být součastí kaž-dého objektového jazyka, z nichž některé dokonce mohou probíhat ažza běhu programu a ne dříve. Situace se v tomto ohledu u staticky adynamicky typovaných jazyků značně liší.

• Kontrola implicitního přetypování (časná/statická vazba)

• Kontrola explicitního přetypování objektu — kontrola typu(třídy) lze provádět až při samotném běhu programu, protoženejsme schopni při překladu s jistotou určit typ objektu, kterýse budume pokoušet explicitně přetypovat (polymorfismus)

• Modifikátory viditelnosti

5.5.2 Interpret

V případě interpretace zdrojového kódu OOJ je situace lehce odlišnáod klasických interpretů ve strukturovaných nebo modulárních jazy-cích. Většinou potřebujeme pro práci v interpretačním režimu k dis-pozici pracovní prostor (angl. workplace). Do tohoto prostoru jsou

obrazy objektové paměti). Čistě textový zápis se většinou omezuje na zápis zdro-jových textů metod a zbylé programovací úkony lze více či méně provádět přesgrafické rozhraní patřičného nástroje. Tato prostředí často obsahují i pokusy o im-plementace vizuálního programování, kdy se vůbec nemusí psát kód.

5.6. ZÁVĚR 85

ukládány všechny dočasné a potřebné objekty, aby se s nimi dalo po-hodlně manipulovat. V interpretech OOJ se více než v jiných jazycíchuplatňuje pravidlo, že doslova všechno je objekt, včetně pravdivost-ních i číselných hodnot. Interpretace probíhá průběžně, což způsobujerychlou odezvu v případě testování a učení (podpora interaktivníhoinkrementálního programování, angl. exploratory programming. Samo-zřejmě v případě výpočtů náročných na výkon není interpretace zpra-vidla dobrým řešením i přes možnosti interní optimalizace, která sevšak navenek nesmí projevovat změnou chování, ale jedině vylepšenírychlosti či spotřeby zdrojů.

Pojmy k zapamatováníVirtuální stroj, mezikód (bytekód), objektová paměť, tabulka virtuál-ních metod. Dále chápat úskalí implementace překladače či interpretuobjektově orientovaného jazyka.

5.6 ZávěrObjektově orientované jazyky jsou velmi mocným nástrojem, kterýje vhodný především pro popis a manipulaci s komplexními struktu-rami a abstrakcemi. Je však potřeba být obezřetný vůči analytikůma manažérům, kteří mívají tendenci výhody objektové orientovanostiznačně přeceňovat, což může ve výsledku vést až k nezdaru projektu.OOJ nabízí mnoho možností a postupů, ale tím také roste riziko, žese systém špatně navrhne. Přestože mají objektově orientované apli-kace na dobré úrovni znovupoužitelnost, róbusnost i udržovatelnost, jenutné vybrat ten správný návrh, protože v případě chyby je přepsánícelého systémů někdy ještě náročnější než třeba u modulárních jazyků.

Kapitola poskytla čtenáři hodnotné informace ze zákulisí objektověorientovaných jazyků a o pokročilých vlastnostech spjatých s objek-tovou orientací. Pro usnadnění rozhodnutí, který jazyk je ten pravýpro odzkoušení té které vlastnosti uvádíme srovnávací tabulku 5.1 pětivýznamných zástupců objektově orientovaného programování.

Při hlubším studiu specifičtějších vlastností OOJ je již efektivní sezaměřit na konkrétní vybraný jazyk, ke kterému bývá k dispozici od-borná publikace nebo minimálně podrobná specifikace jazyka, včetnětipů a triků pro jeho implementaci.


Vlastosti / Jazyky C++ Java Python Smalltalk SELF

Typová kontrola stat. stat. dyn. dyn. dyn.Primitivní typy ano ano ano ne neOrientace třídní třídní třídní třídní obj.Virtuální stroj ne ano ano ano anoGarbage collector ne ano ano ano anoTřídy ano ano ano ano neDědičnost n 1 n 1 nReflexivita ne ano ano ano anoKořenová třída ne ano ne ano —Šablony ano ne ne ne neAbstraktní třídy ano ano ne ne neOperátory ano ano ano b. z. b. z.Priorita operátorů ano ano ano ne ne5

Přetěžování ano ano ano ne neRedefinice metod ano ano ano ano anoKonstruktory ano ano ano ne neDestruktory ano ano ano ne neDestruktor vždy volán ano ne ano — —Dynamické rozhraní objektů ne ne ano ne anoVlastnosti ano ne ano ne neSkrývání metod ano ano ano ne neDynamická dědičnost ne ne ne ne anoObrazy objektové paměti ne ne ne ano ano

Tabulka 5.1: Srovnání vlastností vybraných objektově orientovaných ja-zyků (zkratky: stat. = statická, dyn. = dynamická; obj. = objektová; 1 =jednoduchá, n = násobná; b. z. = binární zprávy)

Úlohy k procvičení:Vyberte si objektově orientovaný jazyk, který není v tabulce 5.1 a dotabulky pro něj doplňte nový sloupec. Pro inspiraci uvádíme něko-lik vhodných kandidátů: PHP 5, JavaScript, C#, VisualBasic.NET,ObjectiveC, CLOS, Object Pascal (Delphi) a Ruby.

5vynucené závorkování

5.6. ZÁVĚR 87

ZávěrV této kapitole jsme se zaměřili na méně sourodý výčet a popis pře-devším zajimavých a moderních vlastností OOP, které jsou většinouvůči tomuto paradigmatu ortogonální (uplatnitelné i v jiných para-digmatech).Po dokončení podrobnějšího dělení jazyků podle způsobů typové kon-troly následují podkapitoly probírající témata týkající se nejen tříd-ních OOJ jako řízení toku v hybridních OOJ, modifikátory viditel-nosti a přetěžování metod. Mezi ještě obecnější mechanismy patříbezesporu výjimky a šablony. Zmínka je i o perzistentních objektecha systémech s rolemi.Zbytek kapitoly se věnuje úskalím překladu a interpretace objektověorientovaných jazyků.

Další zdrojeKvalitní publikace pro studium pokročilejších vlastností a mecha-nismů implementace OOJ již nejsou tak snadno dostupné, v českýchpřekladech zpravidla jen pro nejrozšířenější jazyky (C++, Java):• Arnold, K., Gosling, J., Holmes, D.: The JavaTM Programming

Language, Fourth Edition, Addison Wesley, 2005, ISBN 0-321-34980-6.• Goldberg, A., Robson, D.: Smalltalk-80 - The Language and Its

Implementation (Blue Book), Addison Wesley, 1983.• Eckel B.: Thinking in C++ (Volume 1 & Volume 2), Prentice Hall,

2000-2003.Dostupné na URL http://mindview.net/Books/TICPP/ThinkingInCPP2e.html (únor 2006).

Velmi přínosnou knihou pro budoucí dobré návrháře a programátoryje popis návrhových vzorů:• Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns

– Elements of Reusable Object-Oriented Software, Addison Wesley,1995.


Kapitola 6

Závěr

Tento díl celé publikace představuje v několika kapitolách objektověorientované metody analýzy, návrhu a implementace, kam spadá pře-devším objektově orientované programování.

Hlavní úsilí je kladeno na vysvětlení objektově orientovaného pa-radigmatu a doplnění pasáží, které nejsou přímo dostupné v českéliteratuře. Text se nezaměřuje na konkrétní jazyk a jeho syntaxi a sé-mantiku, ale snaží se poskytnout studentovi ucelený výklad základníchi pokročilejších vlastností jak z hlediska užívání OOJ, tak z hlediskazpracovávání a rozšiřování existujících implementací.

Po absolvování by student měl být schopen podle popsaných vlast-ností objektově orientovaných jazyků tyto jazyky nejen rozpoznat, alei aktivně studovat jejich pokročilejší vlastnosti, a případně se roz-hodovat o použitelnosti toho či onoho jazyka pro řešení konkrétníhoproblému.

Pro doplnění znalostí jsou vhodné moduly pojící se s výklademněkterého konkrétního programovacího jazyka (např. C++, Java neboSmalltalk).

Obsah modulu obsahuje pouze nejnutnější informace a nástiny pro-blematiky. Pro úplné zvládnutí problematiky je vhodné rozšířit si vě-domosti nějakou vhodnou doporučenou literaturou jak z oblasti ob-jektově orientovaných jazyků, tak třeba z okrajových témat.

89

90 KAPITOLA 6. ZÁVĚR

Rejstřík

Abstrakce, 14, 16, 19Abstraktní datový typ, 21Ada, 67Adresát, viz PříjemceAgregace, 55

silná, viz KompoziceAlokace

na haldě, 22na zásobníku, 22

Analýzalexikální, 84sémantická, 84syntaktická, 84

Argument, viz ParametrAsociace, 54

vícenásobná, 54Atribut, 15, 40, 51

modifikace, 40odvozený, 51výběr, 40

base, 29Binární strom, 75, 76Black Box, viz Černá skříňkaBooch, Grady, 14, 49Bytecode, viz BytekódBytekód, 73, 80

C, 14, 26, 67C++, 14, 17–19, 22, 26, 28, 67,

69, 76, 86C#, 19, 22, 24, 28, 69, 72, 84catch-blok, 74Chování, 14CLOS, 69

Černá skříňka, 16

Dahl, Ole-Johan, 14Datový typ, 65

parametrizace, 75Dědičnost, 14, 17, 20, 23

dynamická, 33implementace, 24jednoduchá, 24přímá, 25rozhraní, 24vícenásobná, 22, 24, 32, 69

problémy, 70vyžadovaná, 26

Deep copy, viz Hluboká kopieDelegace, 32Delegovaný objekt, 32Delphi, 26, 28Design Pattern, viz Návrhový

vzorDestruktor, 23

virtuální, 23Diagram, 49

datových toků, 57komponent, 57objektů, 56případů použití, 57rozmístění zdrojů, 57sekvence, 58seskupení, 56spolupráce, 58stavový, 59tříd, 53

Diskriminátor dědičnosti, 55

Exception, viz Výjimky

Finalizační sekce, 73

91

92 REJSTŘÍK

Finalizace, 23Formální návrh, 45Fortran, 67friend, 69

Garbage Collector, 31, 81Generalizace, 54get, 73Goldbergová, Adele, 14Gosling, James, 14Grafické uživatelské rozhraní,

14

Haskell, 72, 74Hierarchie tříd, 24, 25Hluboká kopie, 22

Identita, 17Image, viz Objektová paměťImplicitní předávání odkazem,

23Inicializace, 21Instance, 21, 82Instanciace, 21Instanční metoda, 25Instanční proměnná, 25Interface, viz Rozhraníinternal, 69, 84Interpret, 84Invariant, 16Invokace metody, 40

Jacobson, Ivar, 14, 49Java, 14, 19, 22, 24, 26, 28, 67,

72, 80, 86JavaScript, 33Jazyky

beztypové, 66netypované, 19, 39, 66objektové

čistě, 28hybridně, 28

typované, 66absolutně silně, 67

dynamicky, 19, 28, 30, 33,67

silně, 28, 67slabě, 28, 67staticky, 17, 19, 28, 30, 66středně silně, 67téměř silně, 67

založené na prototypech, 31založené na třídách, 20

Jedináček, 82Jmenný prostor, 68

Kay, Alan, 13, 14Klasifikace jazyků, 65Klíčové slovo, 22Klonování, 31Kompozice, 55Koncepty, 15Konstruktor, 21Kvalifikace jména, 29

λ-kalkul, 66Lisp, 14Literál, 41

vytvoření objektu, 40

Mělká kopie, 22Memory leaks, viz Úbytky pa-

mětiMetamodel, 59Metatřída, 25Metoda, 15

instanční, viz Instanční me-toda

odvozená, 73statická, 79třídní, viz Třídní metodavirtuální, 30

Mezikód, 80Míra abstrakce, 16ML, 67Mnohotvárnost, viz Polymorfis-

musModel

REJSTŘÍK 93

chování, 50reálný, 13softwarový, 13struktury, 50

Modifikátor viditelnosti, 16, 52,68

Modifikace metody, 40Modula-3, 23, 67

Nadtyp, 26Namespace, viz Jmenný prostorNásobnost vztahu, 54Nativní aplikace, 83Návrhový vzor, 82

chování, 82strukturální, 82vytvářecí, 82

Nedefinovaná hodnota, 18new, 22Nultý parametr, 29Nygaard, Kristen, 14

Oberon, 22Object, 28Object Pascal, 26, 28ObjectiveC, 81Objekt, 14, 15, 40, 51

perzistentní, 77reálný, 14

Objektová paměť, 77, 81Odesilatel, 15Operace, 15, 51

abstraktní, 52, 75Optimalizace, 28, 81Ortogonalita, 65

Parametr, 17Pascal, 67Perzistence, 77PHP5, 22Podtyp, 25, 26

skutečný, 26Pohled, 49Polymorfismus, 17, 29

generický, 72Potomek, 24Pracovní prostor, 84private, viz Modifikátor viditel-

nostiProgramování

interaktivní inkrementální,85

objektově orientované, 13objektově založené, 52vizuální, 84

Proměnná, 40instanční, viz Instanční

proměnnátřídní, viz Třídní proměnnávázaná, 41volná, 41

protected, viz Modifikátor vidi-telnosti

Protokol objektu, 15Prototyp, 33Prvek, 50Překladač, 83Přetěžování metod, 69Přetěžování operátorů, 69Příjemce, 15Přiřazení, 18Pseudoproměnná, 29public, viz Modifikátor viditel-

nostiPython, 22, 86

Realizace, 54Redefinice metod, 28Redukce, 42

invokace, 42modifikace, 42

Reference, 18, 23rise, 74Róbustnost, 17, 19Rodič, 24Role, 76Rozhraní, 71

94 REJSTŘÍK

Rozhraní objektu, viz Protokolobjektu

Rozšiřitelnost, 17, 19Ruby, 80Rumbaugh, Jim, 14, 49Rušení instancí, 23Rušení objektů, 31Rys, 32

Sdíleníchování, 17kódu, 17

SELF, 33, 34, 42, 67, 80, 81, 83,86

self, 29, 40Sémantická akce, 40Sémantická kontrola, 84set, 73Shallow copy, viz Mělká kopieShluky objektů, 31Shoda, 17ς-kalkul, 39

sémantika, 42syntaxe, 40

ς-term, 40Simula, 14, 23Singleton, viz JedináčekSlot, 31, 42

rodičovský, 32Smalltalk, 14, 19, 22–25, 28, 67,

69, 80, 81, 83, 86Směrování zpráv, 19, 30Snapshot, viz Objektová paměťSpecializace, viz Generalizacestatic, 26Statická metoda, 26Statická proměnná, 26Stav, 15Stereotyp, 52

rozhraní, 52Stroustrup, Bjorn, 14Subclass, viz PodtypSubstituce, 41

super, 29Superclass, viz NadtypSystém s rolemi, 77

Šablona, 74, 75Šablonový typ, 75

Tabulka virtuálních metod, 30,73

this, 29, 40throw, 74TObject, 28trait, viz Rystry, 74Třída, 20, 51

abstraktní, 52asociační, 54parametrizovaná, 53

Třídní metoda, 25Třídní proměnná, 25Typ, 26Typová chyba, 66Typová inference, 66Typová kontrola, 17

dynamická, 67silná, 66statická, 67

Typový systém, 65

Úbytky paměti, 23Udržovatelnost, 17, 19Ukazatel, 18UML, 14, 44, 49Unified Modeling Language, viz

UMLunion, 67

Variant, 16Vazba

časná, 30pozdní, 30přes jméno, 73

Viditelnost, viz Modifikátor vi-ditelnosti

REJSTŘÍK 95

View, viz PohledVirtuální stroj, 78, 80, 83VMT, viz Tabulka virtuálních

metodvon Neumann, John, 20, 78Výjimky, 73Vztah, 50

Workplace, viz Pracovní pro-stor

Zapouzdření, 16, 19Zasílání zpráv, 14, 15, 18Závislost, 56Znovupoužitelnost, 16, 19Zpráva, 58

96 REJSTŘÍK

Literatura

[1] Abadi, M., Cardelli, L.: A Theory of Objects, Springer, New York,1996, ISBN 0-387-94775-2.

[2] Arlow, J., Neustadt, I.: UML a unifikovaný proces vývoje aplikací,Computer Press, Brno, 2003 (překlad do češtiny, Addison-Wesley,2002), ISBN 80-7226-947-X.

[3] Arnold K., Gosling J., Holmes D.: The JavaTM Programming Lan-guage, Fourth Edition, Addison Wesley, 2005, ISBN 0-321-34980-6.

[4] Brodský, J., Staudek, J., Pokorný, J.: Operační a databázové sys-témy, Technical University of Brno, 1992.

[5] Cattell, G. G.: The Object Database Standard ODMG-93 , Release1.1, Morgan Kaufmann Publishers, 1994.

[6] Cooper, J. W.: C# Design Patterns - A Tutorial, Addison-Wesley,2003, ISBN 0-201-84453-2.

[7] Eckel, B.: Thinking in Java, 3rd Edition, Prentice-Hall, 2002.

[8] Eckel, B.: Thinking in C++, 2nd Edition, Volume 1 & Volume 2,Prentice-Hall, 2000-2003.

[9] Ellis, M. A., Stroustrup, B.: The Annotated C++ Reference Ma-nual , AT&T Bell Laboratories, 1990, ISBN 0-201-51459-1.

[10] Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Pat-terns – Elements of Reusable Object-Oriented Software, AddisonWesley, 1995.

[11] Goldberg, A., Robson, D.: Smalltalk-80 – The Language and ItsImplementation (Blue Book), Addison Wesley, 1983.

[12] Finkel, R. A.: Advanced Programming Language Design, Addison-Wesley, California, 1996.

97

98 LITERATURA

[13] Gordon, M. J. C.: Programming Language Theory and its Imple-mentation, Prentice Hall, 1988, ISBN 0-13-730417-X, ISBN 0-13-730409-9.

[14] Gray, P. M. D., Kulkarni, K. G., Paton, N. W.: Object-OrientedDatabases, Prentice Hall, 1992.

[15] Chonoles M. J., Schardt, J. A.: UML 2 for Dummies, 2003, ISBN0-764-52614-6.

[16] Jones, M. P.: Fundamentals of Object-Oriented Design in UML,Addison-Wesley, 2000.

[17] Kay, A. C.: The Early History of Smalltalk, ACM, 1993.

[18] Khoshafian, S., Abnous, R.: Object Orientation. Concepts, Lan-guages, Databases, User Interfaces, John Wiley & Sons, 1990,ISBN 0-471-51802-6.

[19] Křivánek, P.: Podpora beztřídního programování ve Squeak Small-talku, diplomová práce, FIT VUT Brno, 2005.

[20] Křivánek, P.: Squeak Smalltalk, seriál článků, Root.cz, ISSN 1212-8309, 2003-2005.

[21] Leroy, X.: The Objective Caml system, documentationand user’s guide, 1997, Institut National de Rechercheen Informatique et Automatique, Francie, Release 1.05,http://pauillac.inria.fr/ocaml/htmlman/.

[22] Lindholm, T., Yellin, F.: The Java Virtual Machine Specification,Addison-Wesley, 1996, ISBN 0-201-63452-X.

[23] Merunka, V.: Objektové metody a přístupy - Smalltalk-80, učebnítext.

[24] Prata, S.: Mistrovství v C++, Computer Press, 2004, ISBN: 80-251-0098-7.

[25] Odersky, M., Wadler, P.: Pizza into Java: Translating theory intopractice, Proc. 24th ACM Symposium on Principles of Program-ming Languages, January 1997.

[26] Object Management Group (OMG): Unified Modeling Language- Specification, Version 1.2, 1998.

[27] Robinson, S. a kolektiv: C# Professional , John Wiley and Sons,2003.

LITERATURA 99

[28] Sebesta, R. W.: Concepts of Programming Languages , Forth Edi-tion, Addison-Wesley, 1999, ISBN 0-201-38596-1.

[29] Schmidt, D. A.: The Structure of Typed Programming Languages,MIT Press, 1994.

[30] Schmuller, J.: Sams Teach Yourself UML in 24 Hours, Third Edi-tion, 2004, ISBN 0-672-32640-X.

[31] Švec, M.: Programovací jazyk a aplikační prostředí SELF, FITVUT Brno, 2004.

Documents

Principy programovac´ıch jazyk˚u …pub.eyim.net/ziraficka/IPP-II-ESF-1_1_hyperlinks.pdfPrincipy programovac´ıch jazyk˚u aobjektovˇeorientovan´eho programov´an´ı IPP –