Rozhraní. interface (interfejs) Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st

Transkript

1 Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :46 1 z 58 Rozhraní interface (interfejs)

2 Obsah Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :46 2 z Základní vlastnosti Návrhový vzor SlužebníkChyba! Záložka není definována. 3. Dědění rozhraní Událostmi řízené programování PROZATÍMNÍ KONEC Návrhový vzor Most (Bridge) KONEC... 58

3 1. Základní vlastnosti Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :46 3 z 58 Obsah 1.1 Rozhraní implementace Rozdíly Dvě složky rozhraní Příklad Příklad v BlueJ Získání dokumentace projektu Dokumentace knihovny CanvasManager Získání dokumentace v BlueJ Rozhraní interfejs Interfejs a jeho instance Příklad: Implementace interfejsu IShape Použití interfejsů... 15

4 1.1 Rozhraní implementace Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :46 4 z 58

5 1.1.1 Rozdíly Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :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

6 1.1.2 Dvě složky rozhraní Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :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

7 1.1.3 Příklad Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :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

8 1.1.4 Příklad v BlueJ Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :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

9 1.1.5 Získání dokumentace projektu Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :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

10 1.1.6 Dokumentace knihovny CanvasManager Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :46 10 z 58

11 1.1.7 Získání dokumentace v BlueJ Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :46 11 z 58 Zadáním příkazu Project Documentation v nabídce Tools

12 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 , uloženo st :46 12 z 58

13 Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :46 13 z 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

14 1.4 Příklad: Implementace interfejsu IShape Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :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

15 1.5 Použití interfejsů Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :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

16 2. Návrhové vzory Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :46 16 z 58 Obsah 2.1 Motivace Příklad: plynulý posun obrazců analýza Příklad: plynulý posun obrazců řešení Služebník implementace Způsoby využití služebníka Blikající světlo o obsluhu žádají instance Plynulý posun o obsluhu žádá klient... 26

17 2.1 Návrhové vzory Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :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

18 2.1.1 Návrhové vzory použité v projektu 1/2 Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :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

19 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 , uloženo st :46 19 z 58

20 2.2 Návrhový vzor Služebník motivace Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :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í

21 2.2.1 Příklad: plynulý posun obrazců analýza Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :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ů

22 2.2.2 Příklad: plynulý posun obrazců řešení Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :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

23 2.3 Návrhový vzor Služebník implementace Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :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

24 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 , uloženo st :46 24 z 58

25 2.4.1 Blikající světlo o obsluhu žádají instance Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :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

26 2.4.2 Plynulý posun o obsluhu žádá klient Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :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

27 3. Dědění rozhraní Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :46 27 z 58 Obsah 3.1 Nadhodnocení nároků na přesouvané objekty Snížení nároků zavedením druhého interfejsu Současná implementace více interfejsů Výsledná podoba projektu přešipkováno 3.2 Dědění Princip Tři typy dědění 1/ Tři typy dědění 2/ Implementace interfejsu opakování Dědění interfejsů Použití dědění několika interfejsů Množinový náhled na dědění Projekt se zavedeným děděním rozhraní 3.3 Definice nového interfejsu, značkovací interfejs 4.1 Motivace Vzájemně závislé objekty 4.2 Nástřel řešení: vzor Prostředník Přetrvávající problémy Inverze závislostí 4.3 Návrhový vzor Pozorovatel Motivace Implementace 1/ Implementace 2/2 4.4 Aplikace v projektu CanvasManager CanvasManager změny v přístupu k projektu CanvasManager výhody

28 3.1 Nadhodnocení nároků na přesouvané objekty Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :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

29 3.1.1 Snížení nároků zavedením nového interfejsu Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :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

30 3.1.2 Další interfejs Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :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ě

31 3.1.3 Současná implementace více interfejsů Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :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

32 3.1.4 Výsledná podoba projektu přešipkováno Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :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í

33 3.2 Dědění Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :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

34 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 , uloženo st :46 34 z 58

35 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 , uloženo st :46 35 z 58

36 3.2.3 Tři typy dědění 2/2 Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :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ů

37 3.2.4 Implementace interfejsu opakování Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :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

38 3.2.5 Dědění interfejsů Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :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ů

39 3.2.6 Použití dědění několika interfejsů Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :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ů

40 3.2.7 Množinový náhled na dědění Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :46 40 z 58

41 3.2.8 Projekt se zavedeným děděním rozhraní Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :46 41 z 58

42 3.3 Definice nového interfejsu, značkovací interfejs Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :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

43 4. Událostmi řízené programování Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :46 43 z 58 Obsah 4.1 Motivace Vzájemně závislé objekty Nástřel řešení: vzor Prostředník Přetrvávající problémy Inverze závislostí Návrhový vzor Pozorovatel Motivace Implementace 1/ Implementace 2/ Aplikace v projektu CanvasManager CanvasManager změny v přístupu k projektu CanvasManager výhody... 54

44 4.1 Motivace Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :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é

45 4.1.1 Vzájemně závislé objekty Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :46 45 z 58 pkg _07_Mediator T1 T5 T2 T4 T3

46 Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :46 46 z 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

47 4.2.1 Přetrvávající problémy Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :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

48 4.2.2 Inverze závislostí Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :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

49 4.3 Návrhový vzor Pozorovatel Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :46 49 z 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

50 4.3.2 Implementace 1/2 Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :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

51 4.3.3 Implementace 2/2 Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :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

52 4.4 Aplikace v projektu CanvasManager Copyright Rudolf Pecinovský, Soubor: 02_Rozhrani_x_Interfejs.doc, verze , uloženo st :46 52 z 58

53 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 , uloženo st :46 53 z 58

54 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 , uloženo st :46 54 z 58