Vaše jistota na trhu IT Rozhraní a implementace Rudolf PECINOVSKÝ 2012 – Vývoj bezpečných aplikací 1.

Prezentace na téma: "Vaše jistota na trhu IT Rozhraní a implementace Rudolf PECINOVSKÝ 2012 – Vývoj bezpečných aplikací 1."— Transkript prezentace:

1 Vaše jistota na trhu IT Rozhraní a implementace Rudolf PECINOVSKÝ rudolf@pecinovsky.cz 2012 – Vývoj bezpečných aplikací 1

2 Vaše jistota na trhu IT Rozhraní × Implementace ►Rozhraní × Implementace (odkaz dovnitř)Rozhraní × Implementace 159–176

3 Vaše jistota na trhu IT Rozhraní × Implementace principy ►Rozhraní × Implementace ►Signatura × Kontrakt ►Dokumentační komentáře ►Zásady správného programování 159–176

4 Programování proti rozhraní ►Jedna z hlavních zásad říká, že programovat se má proti rozhraní a ne proti implementaci ►Řada studentů ale stále netuší, co to je rozhraní a k čemu je v programu dobré ►Další možná umějí implementovat interface, ale vůbec netuší, kdy by jej měli zakomponovat do svého návrhu ►=> Následuje malé opakování 2012 – e-bezpečnost v Kraji Vysočina 4

5 ICZ Copyright © 2009, Rudolf Pecinovský 5 Trocha mytologie ►Janus římský bůh vchodů, dveří, počátku a konce ►Měl dvě tváře: jedna hleděla do budoucnosti, druhá do minulosti ►I program má dvě tváře: Rozhraní × Implementace

6 VŠE – 03 Copyright © 2006, Rudolf Pecinovský 6 RozhraníImplementace Definuje, co bude zbytek programu o dané entitě vědět Všem na sebe všechno řekne Zabezpečuje, aby entita plnila svoji funkci Všechno se snaží maximálně utajit I samotné rozhraní má dvě složky ►Signatura Specifikuje vlastnosti, které může zkontrolovat překladač (názvy, typy, …) ►Kontrakt Doplňuje další důležité informace, které však překladač zkontrolovat nedokáže – o jejich dodržení se musí postarat programátor

7 VŠE – 03 Copyright © 2006, Rudolf Pecinovský 7 Příklad – rozhraní ITvar v projektu Tvary

8 Příklad: Přesouvač ►Definici plynulého posunu nebudeme programovat v každé třídě, ale „vytkneme“ ji do zvláštní třídy, která bude všechny tvary obsluhovat ►Instance třídy Přesouvač jsou ochotny plynule přesunout každého, kdo implementuje interface ITvar ►K implementaci se třídy musí veřejně přihlásit Úvod do OOP ICZ, 2011 © Rudolf Pecinovský 8

9 Obsluha instancí neznámí třídy ►Pokud Přesouvač obsluhuje všechny instance rozhraní ITvar, je schopen plynule přesunout i instance třídy, která v době jeho vzniku ještě vůbec neexistovala – stačí, aby třída implementovala ITvar Úvod do OOP ICZ, 2011 © Rudolf Pecinovský 9

10 Zjednodušení požadavků ►Z hlediska objektů, které chtějí být pouze plynule přesouvány, má rozhraní ITvar z předchozího příkladu na implementující třídy zbytečně velké nároky ● Přesouvači by mělo stačit, když instance umí prozradit svoji pozici a umí se přesunout na zadanou pozici; vše ostatní je zbytečné ►Lepší řešení je proto definovat nové rozhraní, např. IPosuvný, které omezí své požadavky na ty, jejichž splnění přesouvač bezpodmínečně potřebuje ►Třída může implementovat několik rozhraní současně ►Můžeme proto definovat a implementovat i další rozhraní, která např. definují požadavky instancí třídy Kompresor na instance, které chtějí plynule měnit svůj rozměr Úvod do OOP ICZ, 2011 © Rudolf Pecinovský 10

11 Implementace více rozhraní ►Když budou všechny třídy tvarů implementovat všechna rozhraní, diagram se opět znepřehlední ►K zpřehlednění diagramu využijeme možnosti definovat mezi rozhraními vztahy dědičnosti: ►Potomek přebírá všechny požadavky předka a může přidat i své vlastní Úvod do OOP ICZ, 2011 © Rudolf Pecinovský 11

12 VŠE – 05 Copyright © 2006, Rudolf Pecinovský 12 Pravidla dědičnosti rozhraní ►Rozhraní může být potomkem jiného rozhraní; svého rodiče pak uvede v hlavičce za slovem extends interface IHýbací extends IPosuvný, INafukovací ►V diagramu tříd znázorňujeme vztah předek–potomek šipkou s trojúhelníkovým koncem ukazujícím k předku ►Dceřiné rozhraní přebírá (dědí) všechny metody deklarované rodičem ►Třídy implementující dceřiné rozhraní musí implementovat všechny jeho metody včetně zděděných

13 Použití v projektu Úvod do OOP ICZ, 2011 © Rudolf Pecinovský 13

14 Vaše jistota na trhu IT Rozhraní × Implementace v Javě ►Rozhraní × Implementace ►Signatura × Kontrakt ►Dokumentační komentáře ►Zásady správného programování 159–176

15 ICZ Copyright © 2009, Rudolf Pecinovský 15 Rozhraní a implementace metody ►Rozhraní – signatura ● Jmenuje se blikni ● Nemá žádné parametry ● Nic nevrací ►Rozhraní – kontrakt ● Světlo nejprve „rozsvítí“ ● Nechá je „svítit“ půl vteřiny ● Po půl vteřině je opět „zhasne“ ►Implementace ● K rozsvícení světla používá svoji metodu rozsviť() ● Půlvteřinové svícení zabezpečí pozastavením programu pomocí metody čekej() třídy IO, které předá počet milisekund čekání ● Zhasnutí realizuje zavoláním své metody zhasni() public void blikni() { rozsviť(); IO.čekej( 500 ); zhasni(); }

16 ICZ Copyright © 2009, Rudolf Pecinovský 16 ►Rozhraní – signatura ● Třída se jmenuje Světlo ● Třída má metody – 4 přetížené verze konstruktorů – rozsviť(), zhasni() – blikni() – getBarva(), getPozice() – getPrůměr(), isZhasnuté() – setPozice(int,int) – setPozice(Pozice) ►Rozhraní – kontrakt ● Co která metoda umí ►Implementace ● Používané atributy ● Realizace jednotlivých metod public class Světlo { private static final Barva ZHASNUTÁ = Barva.ČERNÁ; private final Elipsa žárovka; private final Barva barva; public Světlo() { this( 0, 0 ); } public Světlo( int x, int y ) { this( x, y, Barva.ČERVENÁ ); } public Světlo( int x, int y, Barva barva ) { this( x, y, 50, barva ); } public Světlo( int x, int y, int průměr, Barva barva ) { žárovka = new Elipsa( x, y, průměr, průměr, barva ); this.barva = barva; } public void zhasni() { žárovka.setBarva( ZHASNUTÁ ); } public void rozsviť() { žárovka.setBarva( barva ); } public void blikni() { rozsviť(); IO.čekej( 500 ); zhasni(); } public int getPrůměr() { return žárovka.getŠířka(); } public Barva getBarva() { return barva; } public boolean isZhasnuté() { return žárovka.getBarva() == ZHASNUTÁ; } public Pozice getPozice() { return new Pozice( žárovka.getX(), žárovka.getY() ); } public void setPozice( int x, int y ) { žárovka.setPozice( x, y ); } public void setPozice( Pozice p) { žárovka.setPozice( p.x, p.y ); } Rozhraní a implementace třídy

17 ICZ Copyright © 2009, Rudolf Pecinovský 17 interface – formalizovaný zápis rozhraní ►Java zavedla speciální konstrukci umožňující deklarovat rozhraní bez jakékoliv zmínky o implementaci ►Konstrukce dostala název interface – je to vlastně třída bez implementace ►Signatura rozhraní je dána deklaracemi metod a statických konstant (konstanty se nedoporučuje používat) ►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»

18 ICZ Copyright © 2009, Rudolf Pecinovský 18 Proč používat interface ►Odděluje třídy, které by na sobě jinak vzájemně závisely, a umožňuje je pak měnit nezávisle na sobě (viz NV Most) ►Umožňuje deklarovat požadované vlastnosti zpracovávaných objektů bez ohledu na to, čí instancí tyto objekty budou (viz NV Služebník) ►Umožňuje definovat obecněji koncipované služby (metody) ►Umožňuje zobecnit společné vlastnosti skupiny tříd a definovat pak metody schopné pracovat s instancí kterémkoliv třídy z dané skupiny

19 ICZ Copyright © 2009, Rudolf Pecinovský 19 Rozhraní a moderní programování ►Programujte proti rozhraní, ne proti implementaci (Program to an interface, not an implementation) ►Programátor nesmí využívat své znalosti o implementačních detailech použitých objektů, protože implementace se může záhy změnit ►Při deklaraci dat se snažit využít ten nejobecnější typ, který ještě vyhovuje ● ArrayList -> List -> Collection ►Aktivní obrana: při návrhu využívat definici interface i při definici společného rodičovského typu ● Standardní knihovna kolekcí

20 ICZ Copyright © 2009, Rudolf Pecinovský 20 Knihovna kolekcí – architektura

21 ICZ Copyright © 2009, Rudolf Pecinovský 21 Interní × publikované rozhraní ►Interní (pracovní) rozhraní (= používané jen v projektu) navrhovat tak, aby se minimalizovala pravděpodobnost nutnosti změny ● Modifikace v důsledku jeho změny je pracná, ale řešitelná ● Výrazně ji usnadňují refaktorační nástroje ►Publikované rozhraní = rozhraní, které budou používat externí uživatelé se nesmí měnit ● Není možné zabezpečit korektní reakce na změnu ● Bylo-li navrženo špatně, je nutno definovat nové a označit původní jako zavržené (deprecated) ● I po změně však musí být toto zavržené rozhraní použitelné ve svém původním rozsahu ● Knihovna kolekcí

22 Vaše jistota na trhu IT Děkuji za pozornost ►Rudolf Pecinovský mail: rudolf@pecinovsky.cz ICQ: 158 156 600 2012 – e-bezpečnost v Kraji Vysočina22

23 2012 – e-bezpečnost v Kraji Vysočina 23

24 Pgm Používaná písma a objekty ► Pgm Příliš žluťoučký kůň úpěl ďábelské ódy (Demi) ● Pgm Příliš žluťoučký kůň úpěl ďábelské ódy (Medium) ● Pgm Příliš žluťoučký kůň úpěl ďábelské ódy (Cond) ►Příliš žluťoučký kůň úpěl ďábelské ódy (Heavy) ● Příliš žluťoučký kůň úpěl ďábelské ódy (Franklin Gothic Book) ● Příliš žluťoučký kůň úpěl ďábelské ódy (Comic Sans MS) ● Příliš žluťoučký kůň úpěl ďábelské ódy (Consolas) Program Keyword Opakování Příliš žluťoučký kůň úpěl ďábelské ódy 2012 – e-bezpečnost v Kraji Vysočina 24