Copyright Rudolf Pecinovský, Soubor: 02_Rozhraní x Interfejs.doc, verze , uloženo čt :44 1z 55. Rozhraní. interface (interfejs)

Rozhraní × interface (interfejs)

Copyright © Rudolf Pecinovský, Soubor: 02_Rozhraní x Interfejs.doc, verze 1.00.2413, uloženo čt 9.10.2014 – 12:44

1 z 55

Obsah 1.

Základní vlastnosti .................................................. 3

2.

Návrhový vzor Služebník ...................................... 16

3.

Dědění rozhraní ..................................................... 24

4.

Událostmi řízené programování........................... 40

5.

PROZATÍMNÍ KONEC ............................................ 52

6.

Návrhový vzor Most (Bridge) ............................... 53

7.

KONEC ................................................................... 55


2 z 55

1. Základní vlastnosti 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


3 z 55

1.1 Rozhraní × implementace


4 z 55

1.1.1 Rozdíly ►

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 Copyright © Rudolf Pecinovský, Soubor: 02_Rozhraní x Interfejs.doc, verze 1.00.2413, uloženo čt 9.10.2014 – 12:44

5 z 55

1.1.2 Dvě složky rozhraní ►

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

►

Signatura Specifikuje vlastnosti, které může zkontrolovat překladač

►

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 Copyright © Rudolf Pecinovský, Soubor: 02_Rozhraní x Interfejs.doc, verze 1.00.2413, uloženo čt 9.10.2014 – 12:44

6 z 55

1.1.3 Příklad ►

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


7 z 55

1.1.4 Příklad v BlueJ ►

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


8 z 55

1.1.5 Získání dokumentace projektu ►

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


9 z 55

1.1.6 Dokumentace knihovny CanvasManager


10 z 55

1.1.7 Získání dokumentace v BlueJ ►

Zadáním příkazu Project Documentation v nabídce Tools


11 z 55

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_Rozhraní x Interfejs.doc, verze 1.00.2413, uloženo čt 9.10.2014 – 12:44

12 z 55

1.3 Interfejs a jeho instance ►

Interfejs nemá žádnou implementaci => nemůže mít ani vlastní instance ●

►

Třída se může přihlásit k tomu, že implementuje daný interfejs ●

● ●

►

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ý 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 Copyright © Rudolf Pecinovský, Soubor: 02_Rozhraní x Interfejs.doc, verze 1.00.2413, uloženo čt 9.10.2014 – 12:44

13 z 55

1.4 Příklad: Implementace interfejsu IShape ►

Š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


14 z 55

1.5 Použití interfejsů ►

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

§


15 z 55

2. Návrhový vzor Služebník oblasti

Obsah

2.1 Motivace ............................................................................. 17 2.1.1 Příklad: plynulý posun obrazců – analýza .............. 18 2.1.2 Příklad: plynulý posun obrazců – řešení ................ 19 2.2 Služebník – implementace ................................................ 20 2.3 Způsoby využití služebníka .............................................. 21 2.3.1 Blikající světlo – o obsluhu žádají instance ............ 22 2.3.2 Plynulý posun – o obsluhu žádá klient ................... 23


16 z 55

2.1 Motivace ►

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í Copyright © Rudolf Pecinovský, Soubor: 02_Rozhraní x Interfejs.doc, verze 1.00.2413, uloženo čt 9.10.2014 – 12:44

17 z 55

2.1.1 Příklad: plynulý posun obrazců – analýza ►

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ů


18 z 55

2.1.2 Příklad: plynulý posun obrazců – řešení ►

Ř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


19 z 55

2.2 Služebník – implementace ►

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


20 z 55

2.3 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_Rozhraní x Interfejs.doc, verze 1.00.2413, uloženo čt 9.10.2014 – 12:44

21 z 55

2.3.1 Blikající světlo – o obsluhu žádají instance ►

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


22 z 55

2.3.2 Plynulý posun – o obsluhu žádá klient ►

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

§


23 z 55

3. Dědění rozhraní oblasti

Obsah

3.1 Nadhodnocení nároků na přesouvané objekty............... 26 3.1.1 Snížení nároků zavedením druhého interfejsu....... 27 3.1.2 Současná implementace více interfejsů................. 28 3.1.3 Výsledná podoba projektu – přešipkováno ............ 29 3.2 Dědění ................................................................................. 30 3.2.1 Princip .................................................................... 31 3.2.2 Tři typy dědění 1/2.................................................. 32 3.2.3 Tři typy dědění 2/2.................................................. 33 3.2.4 Implementace interfejsu – opakování .................... 34 3.2.5 Dědění interfejsů .................................................... 35 3.2.6 Použití dědění několika interfejsů .......................... 36 3.2.7 Množinový náhled na dědění ................................. 37 3.2.8 Projekt se zavedeným děděním rozhraní............... 38 3.3 Definice nového interfejsu, značkovací interfejs ........... 39 4.1 Motivace ............................................................................. 41 4.1.1 Vzájemně závislé objekty ....................................... 42 4.2 Nástřel řešení: vzor Prostředník ...................................... 43 Copyright © Rudolf Pecinovský, Soubor: 02_Rozhraní x Interfejs.doc, verze 1.00.2413, uloženo čt 9.10.2014 – 12:44

24 z 55

4.2.1 4.2.2

Přetrvávající problémy............................................ 44 Inverze závislostí .................................................... 45

4.3 Návrhový vzor Pozorovatel .............................................. 46 4.3.1 Motivace ................................................................. 46 4.3.2 Implementace 1/2 ................................................... 47 4.3.3 Implementace 2/2 ................................................... 48 4.4 Aplikace v projektu CanvasManager.................................. 49 4.4.1 CanvasManager – změny v přístupu k projektu ...... 50 4.4.2 CanvasManager – výhody ....................................... 51


25 z 55

3.1 Nadhodnocení nároků na přesouvané objekty ►

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 Copyright © Rudolf Pecinovský, Soubor: 02_Rozhraní x Interfejs.doc, verze 1.00.2413, uloženo čt 9.10.2014 – 12:44

26 z 55

3.1.1 Snížení nároků zavedením druhého interfejsu ►

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

►

Třídy nyní budou implementovat dva interfejsy současně, přičemž požadavky interfejsu IMovable jsou podmnožinou požadavků interfejsu IShape

►

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


27 z 55

3.1.2 Současná implementace více interfejsů ►

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 Copyright © Rudolf Pecinovský, Soubor: 02_Rozhraní x Interfejs.doc, verze 1.00.2413, uloženo čt 9.10.2014 – 12:44

28 z 55

3.1.3 Výsledná podoba projektu – přešipkováno ►

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í


29 z 55

3.2 Dědění ►

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í, nyní si probereme pouze první z nich


30 z 55

3.2.1 Princip ►

Mezi instancemi nějakého typu se často najde skupina instancí se společnými speciálními vlastnostmi ● ● ●

►

OOP umožňuje definovat podtyp charakterizující tuto skupinu; pro značení obou typů používáme názvy: ● ● ● ●

►

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ů

Nadtyp Předek Základní Rodičovský

— — — —

Podtyp Potomek Odvozený typ 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


31 z 55

3.2.2 Tři typy dědění ►

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 ● ● ●

►

1/2

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


32 z 55

3.2.3 Tři typy dědění ►

2/2

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ů


33 z 55

3.2.4 Implementace interfejsu – opakování ►

Při implementaci interfejsu se implementující třída zavazuje implementovat všechny metody deklarované v implementovaném interfejsu a dodržet jejich kontrakt

►

Třída pak může vydávat svoje instance 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 Copyright © Rudolf Pecinovský, Soubor: 02_Rozhraní x Interfejs.doc, verze 1.00.2413, uloženo čt 9.10.2014 – 12:44

34 z 55

3.2.5 Dědění interfejsů ►

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 předků a může přidat i svoje vlastní

►

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 předků Copyright © Rudolf Pecinovský, Soubor: 02_Rozhraní x Interfejs.doc, verze 1.00.2413, uloženo čt 9.10.2014 – 12:44

35 z 55

3.2.6 Použití dědění několika interfejsů ►

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ů


36 z 55

3.2.7 Množinový náhled na dědění


37 z 55

3.2.8 Projekt se zavedeným děděním rozhraní


38 z 55

3.3 Definice nového interfejsu, značkovací interfejs ►

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


39 z 55

4. Událostmi řízené programování oblasti

Obsah

4.1 Motivace ............................................................................. 41 4.1.1 Vzájemně závislé objekty ....................................... 42 4.2 Nástřel řešení: vzor Prostředník ...................................... 43 4.2.1 Přetrvávající problémy............................................ 44 4.2.2 Inverze závislostí .................................................... 45 4.3 Návrhový vzor Pozorovatel .............................................. 46 4.3.1 Motivace ................................................................. 46 4.3.2 Implementace 1/2 ................................................... 47 4.3.3 Implementace 2/2 ................................................... 48 4.4 Aplikace v projektu CanvasManager.................................. 49 4.4.1 CanvasManager – změny v přístupu k projektu ...... 50 4.4.2 CanvasManager – výhody ....................................... 51


40 z 55

4.1 Motivace ►

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é


41 z 55

4.1.1 Vzájemně závislé objekty pkg _07_Mediator T1

T5

T2

T4


T3

42 z 55

4.2 Nástřel řešení: vzor Prostředník ►

Obdobný problém byl i u telefonů – obdobné je i řešení ●

►

Definujeme objekt prostředníka, který zprostředkovává veškerou komunikaci objektů ●

►

Telefony také nejsou spojeny každý s každým, ale spojují se prostřednictvím ústředny pkg _07_Mediator

Vzájemné závislosti objektů se tak omezí na závislost na prostředníku

V našem projektu nahradíme plátno správcem plátna ● ● ●

T1

T5

T2

Prostředník

T4

T3

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á


43 z 55

4.2.1 Přetrvávající problémy ►

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 Copyright © Rudolf Pecinovský, Soubor: 02_Rozhraní x Interfejs.doc, verze 1.00.2413, uloženo čt 9.10.2014 – 12:44

44 z 55

4.2.2 Inverze závislostí ►

Diagram tříd při uplatnění inverze závislostí pkg _07_Mediator <> Komunikující

Prostředník

T1

T2

T3

T4

T5


45 z 55

4.3 Návrhový vzor Pozorovatel 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


46 z 55

4.3.2 Implementace

1/2

►

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


47 z 55

4.3.3 Implementace

2/2

►

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


48 z 55

4.4 Aplikace v projektu CanvasManager


49 z 55

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


50 z 55

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


51 z 55

Copyright Rudolf Pecinovský, Soubor: 02_Rozhraní x Interfejs.doc, verze , uloženo čt :44 1z 55. Rozhraní. interface (interfejs)

Recommend Documents