Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 1 z 58 Rozhraní interface (interfejs)
Obsah Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 2 z 58 1. Základní vlastnosti... 3 2. Návrhový vzor SlužebníkChyba! Záložka není definována. 3. Dědění rozhraní... 27 4. Událostmi řízené programování... 43 5. PROZATÍMNÍ KONEC... 55 6. Návrhový vzor Most (Bridge)... 56 7. KONEC... 58
1. Základní vlastnosti Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 3 z 58 Obsah 1.1 Rozhraní implementace... 4 1.1.1 Rozdíly... 5 1.1.2 Dvě složky rozhraní... 6 1.1.3 Příklad... 7 1.1.4 Příklad v BlueJ... 8 1.1.5 Získání dokumentace projektu... 9 1.1.6 Dokumentace knihovny CanvasManager... 10 1.1.7 Získání dokumentace v BlueJ... 11 1.2 Rozhraní interfejs... 12 1.3 Interfejs a jeho instance... 13 1.4 Příklad: Implementace interfejsu IShape... 14 1.5 Použití interfejsů... 15
1.1 Rozhraní implementace Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 4 z 58
1.1.1 Rozdíly Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 5 z 58 Janus římský bůh vchodů, dveří, počátku a konce Měl dvě tváře: Jedna hleděla do budoucnosti Druhá hleděla do minulosti I program má dvě tváře: Rozhraní Implementaci Rozhraní: definuje, co bude zbytek programu o dané entitě vědět Implementace: zabezpečuje, aby entita plnila svoji funkci
1.1.2 Dvě složky rozhraní Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 6 z 58 I samotné rozhraní má dvě složky: signaturu kontrakt Signatura Specifikuje vlastnosti, které může zkontrolovat překladač Datové typy Počty parametrů Názvy použitých entit Kontrakt Doplňuje další důležité informace, které však překladač zkontrolovat nedokáže a o jejich dodržení se musí postarat programátor
1.1.3 Příklad Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 7 z 58 Zpráva: public Ellipse(Area area, NamedColor color) Signatura: Jedná se o konstruktor, a proto je možno danou zprávu posílat pouze bezprostředně po zaslání zprávy new Ellipse Konstruktor je veřejný (public) => každému dostupný Po zaslání zprávy obdržíme objekt typu Ellipse Zpráva vyžaduje dodání dvou parametrů: První bude typu Area Druhý bude typu NamedColor Kontrakt: Oslovená třída vrátí elipsu zobrazenou na plátně umístěnou v zadané oblasti a vybarvenou zadanou barvou
1.1.4 Příklad v BlueJ Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 8 z 58 Při zasílání zprávy v BlueJ: Nad dělící čarou jsou informace o rozhraní zasílané zprávy Podoba textů pod dělící čarou naznačuje, jak se zaslání zprávy zapíše v kódu Současně jsou zde informace sloužící jako nápověda k lepší identifikaci zadávaných parametrů Při zasílání zprávy vracející hodnotu se navíc zadává identifikátor proměnné, do níž bude tato hodnota uložena
1.1.5 Získání dokumentace projektu Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 9 z 58 Specifikace kontraktu se stává součástí programátorské dokumentace Vývojové platformy nabízejí nástroje umožňující extrahovat tuto dokumentaci ze zdrojového kódu a publikovat v nějaké vhodné podobě Na platformě Java slouží k danému účelu program javadoc; výsledná dokumentace je vytvořena jako soustava HTML stránek Dokumentace standardní knihovny se vytváří stejně, takže pokud se vývojový tým nerozhodne modifikovat šablonu, vypadá dokumentace vyvíjeného programu stejně jako dokumentace standardní knihovny
1.1.6 Dokumentace knihovny CanvasManager Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 10 z 58
1.1.7 Získání dokumentace v BlueJ Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 11 z 58 Zadáním příkazu Project Documentation v nabídce Tools
1.2 Rozhraní interfejs Java zavedla speciální konstrukci umožňující deklarovat rozhraní bez jakékoliv zmínky o implementaci Konstrukce dostala název interface Abych mohl slovo skloňovat, budu v dalším textu používat tvar interfejs Původně to byla třída bez implementace; nyní je možno doplnit implicitní definice instančních metod + definice metod reagujících na zprávy zasílané danému typu Signatura rozhraní je dána deklaracemi metod a statických konstant Kontrakt je (stejně jako u standardních tříd) definován prostřednictvím dokumentačních komentářů Také interface je třeba přeložit, po překladu má vlastní soubor.class V diagramu tříd je doplněn stereotypem «interface» Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 12 z 58
Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 13 z 58 1.3 Interfejs a jeho instance Interfejs nemá žádnou implementaci => nemůže mít ani vlastní instance Rozhraní je jako politik či ideolog: vyhlásí, jak má něco vypadat a jak se to má chovat, ale odpracovat to musí někdo jiný Třída se může přihlásit k tomu, že implementuje daný interfejs Přihlašuje se k tomu veřejně zobrazením šipky k implementovanému interfejsu; tím se toto prohlášení stává součástí její signatury a překladač bude kontrolovat jeho naplnění Instance třídy, která implementuje nějaký interfejs, se mohou vydávat za instance daného interfejsu Třída může implementovat několik interfejsů současně, její instance se pak mohou vydávat za instance kteréhokoliv z nich Kdykoliv se hovoří o instanci interfejsu, hovoří se ve skutečnosti o instanci nějaké třídy, která daný interfejs implementuje
1.4 Příklad: Implementace interfejsu IShape Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 14 z 58 Šipka naznačující implementaci interfejsu je Čárkovaná S trojúhelníkovou hlavičkou Tvarem hlavičky se liší od šipek naznačujících vzájemné závislosti datových typů Implementaci interfejsu Zadáme klepnutím na tlačítko s obrázkem příslušné šipky a následným natažením této šipky od třídy k interfejsu Zrušíme zadáním příslušného příkazu v místní nabídce rušené implementační šipky
1.5 Použití interfejsů Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 15 z 58 Mají-li instance různých tříd některé své schopnosti společné (např. všechny umějí nastavit svoji pozici či rozměr), mají společnou jistou část svého rozhraní => Mohu definovat interfejs, který tuto společnou část specifikuje, a všechny třídy s oněmi společnými vlastnostmi prohlásí, že daný interfejs implementují = definují jím deklarované metody Pak mohu definovat metodu, která akceptuje parametry, které se vydávají (přesněji smějí se vydávat) za instance nějakého interfejsu Aby se instance třídy mohla vydávat za instanci interfejsu, nestačí, aby její mateřská třída definovala požadované metody, třída se musí k implementaci interfejsu explicitně přihlásit
2. Návrhové vzory Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 16 z 58 Obsah 2.1 Motivace... 17 2.1.1 Příklad: plynulý posun obrazců analýza... 21 2.1.2 Příklad: plynulý posun obrazců řešení... 22 2.2 Služebník implementace... 23 2.3 Způsoby využití služebníka... 24 2.3.1 Blikající světlo o obsluhu žádají instance... 25 2.3.2 Plynulý posun o obsluhu žádá klient... 26
2.1 Návrhové vzory Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 17 z 58 Programátorský ekvivalent matematických vzorečků Výhody: 2 b ± b 2 ax + bx + c = 0 x1,2 = 2a 4ac Zrychlují návrh (řešení se nevymýšlí, ale jenom použije) Zkvalitňují návrh Jsou ověřené, takže výrazně snižují pravděpodobnost potenciálních chyb typu na něco jsme zapomněli Zjednodušují a zpřesňují komunikaci mezi členy týmu (větou, že diskriminant je záporný, řeknu znalým jednoduše řadu věcí, které bych musel jinak složitě vysvětlovat) Znalost návrhových vzorů patří k povinné výbavě současného objektově orientovaného programátora
2.1.1 Návrhové vzory použité v projektu 1/2 Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 18 z 58 Knihovní třída (Factory class, Utility) IO Nemá žádnou instanci, nezveřejňuje konstruktor Všechny členy jsou třídní statické Jedináček (Singleton) Canvas Má právě jednu instanci Místo konstruktoru používá jednoduchou tovární metodu Jednoduchá / Statická tovární metoda (Simple / Static factory method) getinstance(), getcanvas() Vrací instanci vlastní třídy; nahrazuje konstruktor Používá se v situacích, kdy je použití konstruktoru nevhodné Nechceme, aby uživatelé mohli vytvářet instance podle libosti
2.1.2 Návrhové vzory použité v projektu 2/2 Výčtový typ (Enumerated type, Enum type) Direction8 Má předem známý počet předem známých instanci Instance jsou deklarovány jako konstanty daného typu Nezveřejňuje konstruktor nelze vytvářet další instance Originál Multiton NamedColor Nemá ekvivalentní instance, každá existuje pouze jednou Každá instance je originál Nemá veřejný konstruktor, místo toho nabízí jednoduchou tovární metodu Mívá předdefinovanou sadu instancí, ale můžete vytvářet další Chová se jako rozšiřitelný výčtový typ Prázdný objekt (Null Object) Direction8, NamedColor Aby metody nemuseli vracet null, definuje se speciální objekt pro případy, kdy nevyhovuje žádná z řádných hodnot Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 19 z 58
2.2 Návrhový vzor Služebník motivace Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 20 z 58 Několik tříd potřebuje definovat stejnou činnost a nechceme definovat na několika místech stejný kód Objekt má úkol, který naprogramovat buď neumíme, nebo bychom jej sice zvládli, ale víme, že je úloha již naprogramovaná jinde Řešení: Definujeme či získáme třídu, jejíž instance (služebníci) budou obsluhovat naše instance a řešit úkoly místo nich Řešení pak bude na jednom místě a bude se snáze spravovat Postup se hodí i tehdy, když připravujeme řešení, které chceme definovat dostatečně obecné, aby je mohli používat všichni, kteří je budou v budoucnu potřebovat, a přitom nevíme, kdo budou ti potřební
2.2.1 Příklad: plynulý posun obrazců analýza Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 21 z 58 V našem příkladu se může hodit v situaci, kdy budeme chtít definovat plynulý posun obrazců Analýza: Plynulý posun simulujeme tak, že: Obrazec zobrazíme, chvíli počkáme, aby jej uživatel zaznamenal v aktuální pozici, obrazec smažeme a posuneme dál a celou akci opakujeme, dokud jej nedostrkáme do cílové pozice Ve všech třídách, jejichž instance chceme posouvat, bychom danou metodu definovali téměř stejně Tím ale porušujeme důležitou programátorskou zásadu Don t Repeat Yourself, jež je podle své zkratky DRY občas označována jako Suchý princip Jejím porušením se namočíte do potenciálních problémů
2.2.2 Příklad: plynulý posun obrazců řešení Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 22 z 58 Řešení: Přesuneme kód na jedno místo, tj. definujeme separátní třídu, jejíž instance služebníci budou umět naše objekty na požádání plynule přesunout Přetrvávající problém: Vzhledem k typové kontrole budeme muset stále definovat více metod pro každý druh objektu jinou Řešení: Naši služebníci budou ochotní přesouvat pouze instance definovaného interfejsu, který musejí implementovat všechny třídy, jejichž instance chceme přesouvat
2.3 Návrhový vzor Služebník implementace Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 23 z 58 Služebník nepracuje sám, ale komunikuje s obsluhovanými instancemi Aby mohl instance bezproblémově obsluhovat, klade na ně požadavky, co všechno musejí umět Služebník proto: Definuje interfejs, v němž deklaruje své požadavky Jeho obslužné metody akceptují jako své parametry pouze instance deklarovaného interfejsu Instance, která chce být obsloužena: Musí implementovat daný interfejs, přesněji musí být instancí třídy implementující daný interfejs, aby se mohla vydávat za instanci tohoto interfejsu Implementací interfejsu deklaruje, že umí to, co od ní služebník k její plnohodnotné obsluze požaduje
2.4 Způsoby využití služebníka Služebník může být využit dvěma způsoby: Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 24 z 58
2.4.1 Blikající světlo o obsluhu žádají instance Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 25 z 58 Chceme po instancích třídy Light, aby uměly blikat zadanou dobu nezávisle na jiné činnosti Cyklus je nepoužitelný, protože po dobu jeho provádění ostatní činnosti stojí Takto není možno naprogramovat ukazatel směru jedoucího auta Využijeme služeb instancí třídy Repeater, jejichž metody umějí opakovat klíčové činnosti svých parametrů Instance opakovače od obsluhovaných vyžadují, aby implementovaly rozhraní Runnable s metodou run(), kterou bude opakovač zadaný-počet-krát opakovat
2.4.2 Plynulý posun o obsluhu žádá klient Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 26 z 58 Objekty projektu IShape se umí přesouvat pouze skokem Pokud bychom chtěli, aby se přesouvaly plynule, museli bychom do každého z nich přidat příslušné metody, které by však byly u všech tříd téměř totožné Seženeme si služebníka přesouvač instanci třídy Mover Služebník ví, že instance interfejsu IShape umějí prozradit a nastavit svoji pozici, a proto umožňuje zaslání zpráv, požadujících plynulý přesun instancí tohoto interfejsu
3. Dědění rozhraní Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 27 z 58 Obsah 3.1 Nadhodnocení nároků na přesouvané objekty 3.1.1 Snížení nároků zavedením druhého interfejsu 3.1.2 Současná implementace více interfejsů 3.1.3 Výsledná podoba projektu přešipkováno 3.2 Dědění 3.2.1 Princip 3.2.2 Tři typy dědění 1/2 3.2.3 Tři typy dědění 2/2 3.2.4 Implementace interfejsu opakování 3.2.5 Dědění interfejsů 3.2.6 Použití dědění několika interfejsů 3.2.7 Množinový náhled na dědění 3.2.8 Projekt se zavedeným děděním rozhraní 3.3 Definice nového interfejsu, značkovací interfejs 4.1 Motivace 4.1.1 Vzájemně závislé objekty 4.2 Nástřel řešení: vzor Prostředník 4.2.1 Přetrvávající problémy 4.2.2 Inverze závislostí 4.3 Návrhový vzor Pozorovatel 4.3.1 Motivace 4.3.2 Implementace 1/2 4.3.3 Implementace 2/2 4.4 Aplikace v projektu CanvasManager 4.4.1 CanvasManager změny v přístupu k projektu 4.4.2 CanvasManager výhody
3.1 Nadhodnocení nároků na přesouvané objekty Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 28 z 58 V prvním přiblížení metody přesouvače (Mover) požadovaly parametry typu IShape; to vyžaduje schopnost reagovat na zprávy: int getx() int gety() void setposition(int x, int y) int getwidth() int getheight() void setsize(int width, int height) void paint() void rubout() IShape copy() Většinu z nich však přesouvač nehodlal poslat
3.1.1 Snížení nároků zavedením nového interfejsu Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 29 z 58 Z předchozích zpráv posílal přesouvač pouze první tři => bylo by rozumné jej uskromnit a definovat interfejs, jehož požadavky se omezí na schopnost reakce na tyto tři zprávy Vyměníme třídu Mover instance té nové se spokojí s implementací skromnějšího interfejsu IMoveable Vyžaduje pouze schopnost prozradit a nastavit svoji polohu, tj. definici metod getx(), gety(), setposition(int,int) Třídy nyní budou implementovat dva interfejsy současně, přičemž požadavky interfejsu IMovable jsou podmnožinou požadavků interfejsu IShape To, že dva různé interfejsy deklarují metody se shodnými signaturami, nevadí, mají-li tyto metody shodné i kontrakty Stejná metoda pak vyhoví oběma požadavkům
3.1.2 Další interfejs Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 30 z 58 Obdobně můžeme přidat třídu Resizer, jejíž instance dokáží plynule měnit velikost instancí interfejsu IResizeable; třídy nyní budou implementovat tři interfejsy Interfejs IResizeable vyžaduje pouze schopnost prozradit a nastavit svoji velikost, tj. definici metod getwidth(), getheight(), setsize(int,int) Tyto metody se opět překrývají s metodami deklarovanými interfejsem IShape; mají ale stejný kontrakt, takže to nevadí Pokud to třída zvládne, může implementovat všechny tři interfejsy současně
3.1.3 Současná implementace více interfejsů Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 31 z 58 Parametry zpráv smějí mít jen jeden typ Budou-li plynule zvětšované objekty instancemi interfejsu IResizeable, připouštějí pouze změnu velikosti, ale ne polohy => smějí se zvětšovat pouze na jihovýchod (viz obrázek), resp. zmenšovat na severozápad Aby se mohly zvětšovat i jinam, musely by být explicitně schopny měnit i svoji polohu např. tak, že by současně implementovaly interfejs IMoveable, protože o jeho instancích se ví, že to umějí Jedinou možností je definovat interfejs (např. IChangeable), jenž by po instancích implementujících tříd vyžadoval schopnost měnit polohu i velikost
3.1.4 Výsledná podoba projektu přešipkováno Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 32 z 58 Po uvedených úpravách se projekt dostane do stavu na obrázku V tomto projektu šipky je tolik implementačních šipek, že se jednotlivé závislosti začínají ztrácet Je třeba využít konstrukci, která celý projekt zpřehlední použijeme dědění
3.2 Dědění Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 33 z 58 Dědění je jedna z klíčových konstrukcí objektového programování Bohužel, je to konstrukce, jejíž vlastnosti mnozí programátoři chápou nepřesně, aniž by si to uvědomovali, a proto zanášejí do svých programů skryté chyby Existují tři druhy dědění: Dědění rozhraní Dědění implementace Nativní dědění V této a několika příštích lekcích budeme používat pouze první z nich
3.2.1 Princip Mezi instancemi nějakého typu se často najde skupina instancí se společnými speciálními vlastnostmi Notebooky či sálové počítače jsou speciální druhy počítačů Psy, kočky, koně atd. jsou speciální druhy savců HTML dokumenty jsou speciálním druhem dokumentů OOP umožňuje definovat podtyp charakterizující tuto skupinu; pro značení obou typů používáme názvy: Nadtyp Podtyp Předek Potomek Základní Odvozený typ Rodičovský Dceřiný Instance potomka přebírají rozhraní svého rodiče říkáme, že je zdědí Instance potomka jsou pouze speciální podmnožinou instancí rodiče, proto se mohou kdykoliv vydávat (alespoň formálně) za instance rodiče Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 34 z 58
3.2.2 Tři typy dědění 1/2 Dědění typů = dědění rozhraní Potomek dodrží všechny vlastnosti a schopnosti předka, tj. převezme jeho signaturu a dodrží jeho kontrakt, a může se proto kdykoliv plnohodnotně vydávat za předka Příklad: třída implementující nějaké rozhraní Dědění implementace Potomek převezme od předka jeho implementaci, takže převzaté funkce nemusí definovat sám Příklad: Všechny třídy přebírají základní metody od třídy Object Nebezpečí: při přizpůsobování zděděných entit potřebám potomka není občas dodržen kontrakt předka Přirozené dědění Jak chápeme vztah obecný speciální bez ohledu na programování Příklad: Čtverec je speciální druh obdélníku, ale nemůže se vydávat za obecný obdélník, protože namůže libovolně změnit velikost svých stran Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 35 z 58
3.2.3 Tři typy dědění 2/2 Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 36 z 58 V dobře napsaném programu jsou všechny tři typy dědění v harmonii Je-li jeden aspekt použité dědičnosti v rozporu s ostatními, narušuje se stabilita programu a jeho rozšiřitelnost Při implementaci interfejsů a při jejich dědění se uplatní pouze dědění typů, protože interfejs žádnou implementaci nemá (alespoň tak, jak jsme jej doposud probírali) Dědění implementace svádí programátory k použití, které je v rozporu s děděním typů, a proto je vykládáme až po zvládnutí dědění typů
3.2.4 Implementace interfejsu opakování Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 37 z 58 V jazycích s přísnou typovou kontrolou (Java, C#, Scala, Swift, ) se při implementaci interfejsu se implementující třída zavazuje implementovat všechny metody deklarované v implementovaném interfejsu a dodržet jejich kontrakt Instance třídy implementující nějaký interfejs se mohou vydávat za instance daného interfejsu Z hlediska dědění považujeme implementovaný interfejs za předka implementující třídy, takže předchozí tvrzení můžeme považovat za speciální případ tvrzení, že instance potomka se může vydávat za instanci předka Podmínkou správné funkce je dodržení kontraktu; ten ale překladač zkontrolovat nedokáže, takže jeho dodržení a kontrola je plně na bedrech programátora
3.2.5 Dědění interfejsů Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 38 z 58 Při dědění potomek deklaruje, kdo je jeho předek V Javě smí interface deklarovat, že má několik bezprostředních předků současně public interface Potomek extends Předek1, Předek2 Potomek přebírá všechny deklarace všech svých předků a může přidat i svoje vlastní Protože totéž udělá předek, dědí i deklarace prapředků Třída implementující potomka interfejsu tak zákonitě implementuje každého z jeho předků => instance třídy implementující interfejs se může vydávat nejenom za instanci daného interfejsu, ale také za instanci kteréhokoliv z jeho (pra)předků
3.2.6 Použití dědění několika interfejsů Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 39 z 58 Metoda vyžaduje, aby její parametr implementoval dva různé interfejsy Java neumožňuje deklarovat, že parametr je současné instancí dvou různých typů Tuto nemožnost lze obejít tak, že definujeme interfejs, který je potomkem obou interfejsů, a deklarujeme parametr jako instanci tohoto potomka To řeší náš motivační příklad s vylepšeným plynulým měněním rozměru tvarů
3.2.7 Množinový náhled na dědění Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 40 z 58
3.2.8 Projekt se zavedeným děděním rozhraní Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 41 z 58
3.3 Definice nového interfejsu, značkovací interfejs Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 42 z 58 Interfejs vytváříme stejně jako třídu, pouze v dialogovém okně nastavíme přepínač Typ třídy (ClassType) na hodnotu Rozhraní (Interface) Implementaci interfejsu zadáme: Ručně přímým zápisem v kódu Natažením šipky od třídy k implementovanému rozhraní Značkovací interfejs (anglicky marker interface nebo tagging interface) Nevyžaduje implementaci metod Jeho implementací se třída pouze hlásí k jím deklarovanému kontraktu
4. Událostmi řízené programování Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 43 z 58 Obsah 4.1 Motivace... 44 4.1.1 Vzájemně závislé objekty... 45 4.2 Nástřel řešení: vzor Prostředník... 46 4.2.1 Přetrvávající problémy... 47 4.2.2 Inverze závislostí... 48 4.3 Návrhový vzor Pozorovatel... 49 4.3.1 Motivace... 49 4.3.2 Implementace 1/2... 50 4.3.3 Implementace 2/2... 51 4.4 Aplikace v projektu CanvasManager... 52 4.4.1 CanvasManager změny v přístupu k projektu... 53 4.4.2 CanvasManager výhody... 54
4.1 Motivace Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 44 z 58 Objekty se při pohybu nejprve smažou v původní pozici, aby se pak nakreslily v nové; při tom občas odmažou i část svých kolegů Aby objekt mohl zrekonstruovat svůj obraz, musel by mu někdo poslat zprávu Vysílač je vždy závislý na příjemci, protože změna jeho rozhraní může ovlivnit požadovaný způsob zasílání zpráv Když bude každý umět každému poslat zprávu, velmi se zvýší počet vzájemných závislostí, které zhoršují spravovatelnost Každá změna nás nutí zkontrolovat všechny závislé objekty Musí-li se změnit závislý objekt, dominovým efektem se problém propaguje na všechny objekty, které jsou na něm závislé
4.1.1 Vzájemně závislé objekty Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 45 z 58 pkg _07_Mediator T1 T5 T2 T4 T3
Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 46 z 58 4.2 Nástřel řešení: vzor Prostředník Obdobný problém byl i u telefonů obdobné je i řešení Telefony také nejsou spojeny každý s každým, ale spojují se prostřednictvím ústředny Definujeme objekt prostředníka, který zprostředkovává veškerou komunikaci objektů Vzájemné závislosti objektů se tak omezí na závislost na prostředníku pkg _07_Mediator T5 T1 Prostředník T2 V našem projektu nahradíme T4 plátno správcem plátna Má na starosti správný vzhled Když objekt mění svoji podobu, řekne správci Správce pak požádá o překreslení všechny, jichž se to týká T3
4.2.1 Přetrvávající problémy Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 47 z 58 Zavedením prostředníka snížíme počet vzájemných závislostí, avšak neodstraníme nebezpečí vzniku dominového efektu Změní-li se definice třídy komunikující s prostředníkem, musíme se podívat, nemá-li se změnit i prostředník, a pokud ano, tak se dominovým efektem rozšíří nutnost kontroly na ostatní objekty komunikující s prostředníkem Potřebujeme zabezpečit, aby prostředník na nikom nezávisel Použijeme postup uplatněný u služebníka: prostředník definuje interfejs a bude ochoten komunikovat pouze s objekty vydávajícími se za instance tohoto interfejsu Tím otočíme směr závislostí a přinutíme komunikující objekty přizpůsobit se požadavkům prostředníka, aniž by se on musel někdy přizpůsobovat jim
4.2.2 Inverze závislostí Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 48 z 58 Diagram tříd při uplatnění inverze závislostí pkg _07_Mediator Prostředník <<interface>> Komunikující T1 T2 T3 T4 T5
4.3 Návrhový vzor Pozorovatel Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 49 z 58 4.3.1 Motivace Objekt čekající na výskyt nějaké události má dvě možnosti: Neustále se ptát iniciátora události, zda už nastala Oslík v 2. dílu Shreka se neustále ptá Už tam budem? Řidič čekající na zelenou neustále sleduje semafor Dohodne se s iniciátorem, že dohodnutým způsobem oznámí, až událost nastane V lůžkovém vlaku vás průvodčí vzbudí před cílovou stanicí Řidič na semaforu v klidu čte mapu v očekávání, že ti za ním na něj zatroubí SMS oznámí příchod peněz na konto
4.3.2 Implementace 1/2 Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 50 z 58 Návrhový vzor pozorovatel řeší problém druhým způsobem, je však třeba dohodnout způsob oznámení výskytu události Vzor má několik názvů odvozených z názvů komunikujících objektů Pozorovatel (Observer) Pozorovaný (Observable) Posluchač (Listener) Vysílač (Broadcast, Sender) Vydavatel (Publisher) Předplatitel (Subscriber) Posluchač (pozorovatel, předplatitel) se musí přihlásit u vysílače (pozorovaného, vydavatele) Vysílač je ochoten přijmout přihlášku pouze od objektů implementujících jím deklarovaný interfejs definující jak objektu oznámit, že došlo k očekávané události
4.3.3 Implementace 2/2 Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 51 z 58 Posluchač se po přihlášení o událost dál nestará a hledí si svého Až vysílač zavolá dohodnutou metodu, pak zareaguje Tento přístup k řešení problému a architektury projektů bývá označován jako Událostmi řízené programování (Event driven programming) Tímto způsobem se řeší veškeré GUI a řada dalších projektů Ve vyšší podobě se používá i ve webových a aplikačních serverech
4.4 Aplikace v projektu CanvasManager Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 52 z 58
4.4.1 CanvasManager změny v přístupu k projektu Třídy, jejichž instance mají být zobrazovány na plátně, musí implementovat interfejs IPaintable Interfejs vyžaduje implementaci metody void paint(painter), kterou správce plátna (instance třídy CanvasManager) zavolá v okamžiku, kdy se má oslovený objekt nakreslit Metoda dostane v parametru kreslíře instanci třídy Painter, což je jediný objekt, který ví, kde je plátno, a umí na něj kreslit Objekt se nakreslí tak, že kreslíři vysvětlí, jak jej má nakreslit, a ten jej nakreslí Objekt, který chce být zobrazován na plátně, se musí zaregistrovat u správce plátna posláním zprávy add(ipaintable...) Objekty se kresli v pořadí, v jakém se zaregistrovaly, tj. dříve zaregistrované objekty vespod, později zaregistrované nad nimi Zpráva povoluje proměnný počet parametrů, takže lze zaregistrovat více objektů najednou, přičemž se registrují v pořadí zleva doprava Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 53 z 58
4.4.2 CanvasManager výhody Takto koncipovaný projekt umožňuje pohybovat objekty (tj. měnit jejich pozice a velikosti), aniž by to mělo vliv na kvalitu zobrazení aktuálního stavu Projekt umožňuje přidávat další třídy s dalšími schopnostmi stejně tak jako další interfejsy s dalšími požadavky Projekt se může stát základem schematického zobrazení různých simulovaných procesů Projekt funguje do jisté míry jako superplatforma, tj. platforma poskytující ekvivalentní možnosti nad různými platformami Umožňuje realizovat relativně rozsáhlé spektrum výukových úloh jen s minimálním využíváním standardní knihovny Díky tomu je převod programů mezi platformami (např. z Javy do.net či zpět) převážně věcí převodu syntaxe Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze 1.00.2413, uloženo st 12.10.2016 19:46 54 z 58