Vývoj bezpečných aplikací

Transkript

1 Vaše jistota na trhu IT Vývoj bezpečných aplikací Rudolf PECINOVSKÝ 2012 e-bezpečnost v Kraji Vysočina 1

2 Vaše jistota na trhu IT Obsah s odkazy Quo vadis, programování? Co je to bezpečné? Zásady správného a bezpečného programování 2012 e-bezpečnost v Kraji Vysočina 2

3 Vaše jistota na trhu IT Quo vadis, programování? 2012 e-bezpečnost v Kraji Vysočina 3

4 Programování se vyvíjí (1/3) Dříve Řada běžných, často se vyskytujících úloh stále čekala na vyřešení Nyní Většina běžných úloh je vyřešena a řešení jsou dostupná v komponentách či knihovnách Programy pracovaly samostatně, navzájem příliš nespolupracovaly Nové program jsou téměř vždy součástí rozsáhlejších aplikací a rámců Klíčovou úlohou programátora byl návrh algoritmů a základních datových struktur Klíčovou úlohou je návrh architektury systému Důležitější než znalost algoritmů je znalost knihoven a aplikačních rámců, v nichž jsou potřebné algoritmy a datové struktury připraveny 2012 e-bezpečnost v Kraji Vysočina 4

5 Programování se vyvíjí (2/3) Dříve Metodika vývoje programů počítala s pevným zadáním Zákazníci hledali firmu, která jejich projekt naprogramuje O výsledné podobě projektu rozhodovali analytici a programátoři Při vývoji programů se kladla váha především na jejich efektivitu U programátorů byla oceňována jejich schopnost vyvíjet programy, s malými HW požadavky Nyní Zadání většiny vyvíjených projektů se v průběhu vývoje neustále mění Programátorské firmy hledají zákazníky, kteří si u nich objednají tvorbu projektu O výsledné podobě projektu rozhoduje zákazník Při vývoji programů se klade váha především na jejich spravovatelnost a modifikovatelnost U programátorů je oceňována jejich schopnost vyvíjet programy, které je možno rychle a levně přizpůsobovat neustále se měnícím požadavkům zákazníka 2012 e-bezpečnost v Kraji Vysočina 5

6 Programování se vyvíjí (3/3) Dříve Prvotní úlohou programátora bylo vymyslet, jak úkol vyřešit Nyní Prvotní úlohou programátora je zjistit, jestli už někde není problém vyřešen Testy se většinou navrhovaly po dokončení projektu či jeho části a spouštěly se na závěr před odevzdáním projektu (byl-li čas) Stále častěji se testy navrhují před začátkem vývoje každé části a spouští se v průběhu celého vývoje po každé drobné změně Testy navrhovali programátoři a ověřovali v nich, že program dělá to, co chtěl programátor naprogramovat Testy se navrhují ve spolupráci se zákazníkem a ověřuje se v nich, že program dělá to, do po něm zákazník požadoval Návrh testů byl interní záležitostí vývojového týmu Návrh testů se často stává součástí smlouvy o vývoji programu 2012 e-bezpečnost v Kraji Vysočina 6

7 Vaše jistota na trhu IT Co je to bezpečné? Bezpečné zabezpečené aplikace Nebezpečnost geniálních programátorů Používané paradigma Nevýhody předčasné koncentrace na kód Problémy přechodu na nové paradigma 2012 e-bezpečnost v Kraji Vysočina 7

8 Bezpečné zabezpečené aplikace Bezpečná aplikace = aplikace, která je robustní vůči uživateli i vůči programátoru, který dostane za úkol ji upravit anebo rozšířit Zabezpečená aplikace = aplikace s dodatečnými nadstavbovými prvky, které mají zabránit případným útočníkům v realizaci jejich nekalých úmyslů Aplikaci, která není primárně vytvořena jako bezpečná, nezabezpečí žádné dodatečné zabezpečovací mechanizmy Existuje i druhý pohled: Bezpečná aplikace je taková, která firmě bezpečně přináší zisk Aplikace, která není bezpečná z programátorského hlediska nebude bezpečná ani z hlediska účetního, protože bude mít špatnou pověst (moc se jí neprodá) a navíc její údržba bude neúnosně drahá 2012 e-bezpečnost v Kraji Vysočina 8

9 Nebezpečnost geniálních programátorů Napsat program, kterému rozumí počítač, dokáže každý trouba, dobří programátoři píší programy, kterým rozumějí lidé. Martin Fowler, Refactoring Zkušenost ukazuje, že programátor vytvářející programy, kterým jeho kolegové nerozumí, je pro firmu stejně nebezpečný jako záměrný záškodník Když takovéhoto geniálního programátora zlanaří jiný zaměstnavatel nebo se stane obětí dopravní nehody, musí firma celou jím navrženou část aplikace zahodit a nahradit jinou Nemusím umět napsat stejně geniální program jako kolega, ale když už jej kolega vytvoří, měl by být pro mě natolik srozumitelný, abych v něm dokázal udělat jednoduché úpravy 2012 e-bezpečnost v Kraji Vysočina 9

10 Jednoduchý příklad nesrozumitelného kódu Klasický zápis programátorů v jazyce C int znak; while ((znak = bufreader.read())!= očekávaný); Zápis, který preferují méně zkušení programátoři int znak; do { znak = bufreader.read(); } while (znak!= očekávaný); 2012 e-bezpečnost v Kraji Vysočina 10

11 Používané paradigma Bezpečnost aplikace je do značné míry závislá na použitém paradigmatu Složitost programů se stále zvětšuje, avšak kapacita mozku zůstává konstantní V průběhu 80 let se proto prosadilo objektové paradigma, které umožňuje psát větší, robustnější a snáze spravovatelné programy Výzkumy ukázaly, že tvorba programů větších než příkazů je předobjektovými technologiemi jen těžko realizovatelná Zastánci tradičních paradigmat tvrdí, že stačí dodržovat zásady modularity. Bohužel nestačí; OO paradigma přináší několik konstrukcí, které přibližují náš programový popis simulované skutečnosti a umožňuje tak efektivnější a současně robustnější realizaci Publikace o programování bezpečných aplikací už většinou ani s jiným než s objektovým přístupem nepočítají 2012 e-bezpečnost v Kraji Vysočina 11

12 Nevýhody předčasné koncentrace na kód Kurzy programování na školách se většinou soustředí na kód a opomíjejí nutnost výuky výrazně jiného způsobu myšlení, namísto OO paradigmatu učí jenom kódování v OO jazyce Absolventi těchto kurzů dále vyvíjejí své strukturované programy, jenom je nyní vyvíjejí v objektově orientovaném jazyce Takto vychovaný programátor myslí a hovoří v termínech kódu; mezi ním a zákazníkem vzniká sémantická mezera Common

13 Problémy přechodu na nové paradigma Trocha psychologie Děti před pubertou jsou schopny přijmout nová fakta, aniž by si je musely spojovat s tím, co již znají; s postupným získáváním dalších informací si předchozí informace propojují a zařazují do kontextu Puberta mění naše myšlení z konkrétního na abstraktní a při té příležitosti nás o tuto schopnost připraví Člověk po pubertě si každý nový poznatek okamžitě podvědomě propojí s tím, co zná, i když při tom často dojde k výrazné dezinterpretaci Strukturovaný programátor při výkladu OOP podvědomě převádí vysvětlované termíny do paradigmatu, v němž je doma Problémem tohoto přechodu je k výrazná desinterpretace pojmů, v hlavě zůstane něco jiného, než co přednášející říkal Na počátku kurzu se domnívá, že slyší triviality, aby v další části zjistil, že se nechal zmást svou předchozí zkušeností a nyní se v termínech ztrácí Přechod trvá typicky měsíců; čím zkušenější je přeškolovaný programátor, tím delší a bolestivější je jeho přechod 2012 e-bezpečnost v Kraji Vysočina 13

14 Vaše jistota na trhu IT Zásady programování bezpečných aplikací Architektonické zásady Jednoduchost Zapouzdření a rozhraní Průzračnost kódu i aplikace Modifikovatelnost a rozšiřitelnost Jasné rozdělení zodpovědností Neopakovat kód s podobnou funkcí A další 2012 e-bezpečnost v Kraji Vysočina 14

15 Architektonické zásady Dobře navržená architektura výrazně snižuje pravděpodobnost vzniku slabých míst napadnutelných útočníkem Maximalizovat soudržnost (maximize cohesion) Míra soudržnosti označuje jak spolu souvisí funkcionalita jednotlivých části daného modulu Řešení úkolu by nemělo být rozcourané po programu Části programu s podobnou funkcionalitou by měly být součástí společné komponenty a naopak by se v ní neměly vyskytovat součásti řešící něco zcela jiného Minimalizovat provázanost (minimize coupling) Při definici každé entity bychom měli minimalizovat počet entit, které daná entita pro splnění daného úkolu oslovuje S konkrétními pravidly přichází zákon bohyně Demeter e-bezpečnost v Kraji Vysočina 15

16 Jednoduchost Čím je kód složitější, tím snáze přehlédneme dírku pro útočníka KISS (Keep it simple, Stupid!) Principle of good enough (POGE) Jednoduchý kód je vytvořen rychleji, obsahuje méně chyb, je robustnější a snadněji se modifikuje Často se také formuluje : vytvoř to nejjednodušší, co ještě bude fungovat Nevytvářejte YAGNI (You aren t going to need it) Řada programátorů má nutkavou potřebu vytvářet podprogramy, které by se mohly hodit; vytvářejte je, až budou opravdu potřeba, protože snižují robustnost kódu viz princip KISS e-bezpečnost v Kraji Vysočina 16

17 Zapouzdření a rozhraní Minimalizovat dostupnost informací použitelných pro napadení Zapouzdření: Zveřejněte, co umíte, ale tajte, jak to děláte Programátor musí u každé entity (třída, objekt, metoda, ) jasně oddělit, co musí okolní program o dané entitě vědět, aby ji mohl použít, a co definoval jenom proto, aby daná entita plnila svůj úkol Programujte proti rozhraní, ne proti implementaci Programátor by nikdy neměl využívat toho, jak je některá část programu definována, leda by tato skutečnost byla přímo uvedena v dokumentaci a stala se tak součástí rozhraní používané entity (třída, objekt, metoda, ) e-bezpečnost v Kraji Vysočina 17

18 Průzračnost kódu i aplikace Kód, v němž se nevyznáme, se hůře zabezpečuje proti případným záměrným útokům Tvořte kód pro potenciálního modifikátora Každá aplikace, která za něco stojí, bude v budoucnu upravována => pište tak, aby byly případné budoucí úravy co nejjednodušší Princip minimálního překvapení (Principle of least astonishment) Nenuť mne přemýšlet (Don t make me think) Kód by měl být srozumitelný s minimálním mentálním úsilím Aplikace by měla respektovat zavedené zvyklosti a očekávání a nevymýšlet si na budoucího uživatele (ani programátora) žádné překvapující obraty e-bezpečnost v Kraji Vysočina 18

19 Modifikovatelnost a rozšiřitelnost Připravenost kódu k modifikacím zvyšuje pravděpodobnost, že modifikace budou udělány čistě a nevzniknout skryté slabiny Open/Close Principle Jednotlivé části kódu by měly být uzavřeny vůči přímým modifikacím, ale otevřeny vůči dalším rozšířením Jakmile je kód jednou dokončen, mělo by se do něj zasahovat pouze při opravách objevených chyb; nové funkce by měly být realizovány pouze přidáním dalšího kódu Připravenost na změny zadání Při návrhu programu bychom měli počítat s tím, že jedinou konstantou současného programování je jistota, že zadání se brzy změní e-bezpečnost v Kraji Vysočina 19

20 Jasné rozdělení zodpovědností Potřebujeme usnadnit budoucí rozhodnutí kam sáhnout, abychom kód požadovaně upravili, a současně minimalizovat množství potřebných zásahů Princip jediného odpovědného (objektu) Single Responsibility Principle Každá část kódu by měla být zodpovědná za jedinou věc, měla by mít jediný, dobře definovaný úkol Oddělení zodpovědností (Separation of concerns SoC) Různá funkcionalita by měla být řešena různými částmi kódu, které by se měly překrývat pouze minimálně To ovšem neznamená, že by různé části kódu nemohly používat společné entity e-bezpečnost v Kraji Vysočina 20

21 Neopakovat kód s podobnou funkcí Objevuje-li se stejný či podobný kód na více místech, musíme při každé modifikaci oběhnout všechna tato místa a všude příslušný kód správně opravit DRY - Don t repeat yourself ; DIE Duplication is Evil Zavrhněte programování copy-paste, neopakujte znovu dříve napsaný kód Princip korektní abstrakce Každá důležitá část funkcionality by měla být implementována na jednom místě. Řeší-li několik částí kódu podobnou funkci, měli bychom je abstrahovat jako obecnější princip a společné jádro pak definovat na jednom místě e-bezpečnost v Kraji Vysočina 21

22 A další Neukládejte důvěrné informace jako běžný text Verifikujte všechny vstupy uživatele Vyvarujte se předčasných snah o optimalizace 60 % zkrachovalých projektů krachuje právě kvůli předčasným snahám o optimalizaci kódu Nechovejte se podle hesla: Proč řežete tupou pilou? Nemáme čas ji nabrousit Sledujte nové trendy v programování OOP, návrhové vzory, nová paradigmata, paralelní programování Sledujte nové technologie Frameworky, jazyky Naučte se anglicky, nebo změňte povolání 2012 e-bezpečnost v Kraji Vysočina 22

23 Vaše jistota na trhu IT Pachy v kódu 2012 e-bezpečnost v Kraji Vysočina 23

24 Uvnitř tříd 1/4 Dlouhé metody Kratší metody se lépe čtou a jsou celkově pochopitelnější Kratší metody obsahují méně chyb a snáze se udržují Komentáře Všechny veřejné metody by měly mít dokumentační komentáře; jejich vynechání je omluvitelné pouze u těch nejjednodušších metod se samovysvětlujícími názvy (většinou getry a setry ) Komentáře by měly vysvětlovat PROČ a ne CO; neměly by duplikovat kód Nutnost použít komentáře bývá často příznakem toho, že metoda je příliš složitá a bylo by ji vhodné rozdělit na několik metod jednodušších Dlouhé seznamy parametrů Snižují srozumitelnost kódu Zavání tím, že kód bude zbytečně složitý Často je výhodné nahradit seznam parametrů přepravkou 2012 e-bezpečnost v Kraji Vysočina 24

25 Uvnitř tříd 2/4 Opakování stejného či podobného kódu Potenciální problémy při úpravách kódu Musíme si pamatovat, kam všude jsme upravovaný kód zkopírovali Na všech místech jej správně upravit Příliš složité podmínky a větvení V převážné většině případů se po rozbití složitých podmíněných konstrukcí kód nejenom zpřehlední, ale také zrychlí Kombinatorická exploze V mnohých případech se objevuje množství variant kódu, které se navzájem liší pouze v maličkostech Často pomáhá vhodné zavedení genericity nebo použití návrhového vzoru Dekorátor Názvy typů v názvech metod Pokud musíte náhodou upravit název typu, musíte pak upravovat i názvy postižených metod 2012 e-bezpečnost v Kraji Vysočina 25

26 Uvnitř tříd 3/4 Velké třídy Jsou stejně obtížně čitelné a spravovatelné jako dlouhé metody Většinou porušují řadu další zásad, především zásadu, že každý objekt (a tím je i třída) má být zodpovědný za jedinou, přesně definovanou věc Kryptické názvy tříd, metod a proměnných Z názvu by mělo být vždy patrné, co má daný objekt na starosti a za co je zodpovědný Nekonzistentní názvy Stejná věc by se měla pokaždé nazývat stejně Java: length size Mrtvý kód Nepoužívaný kód by měl být odstraněn dříve, než jej někdo omylem použije, a to nejspíš spatně Díky správě verzí se k němu můžeme v případě potřeby vrátit 2012 e-bezpečnost v Kraji Vysočina 26

27 Uvnitř tříd 4/4 Zbytečná obecnost Tvořte kód, který řeší současné problémy, a nepřemýšlejte zbytečně nad řešením problémů, které by možná mohly někdy nastat až nastanou, budou se řešit Podivuhodná řešení Řešení problému by mělo být přímočaré a průzračné Podivuhodná řešení jsou často zbytky po duplikovaném a následně všelijak přizpůsobovaném kódu Pomocné atributy Množství pomocných, dočasných atributů bývá příznakem špatně navrženého kódu 2012 e-bezpečnost v Kraji Vysočina 27

28 Příklad důsledku špatného názvu public Vec odebervec(string vec) {//Špatný název parametru for (Vec cokoli2: seznamveci) { if (vec.getnazev().equals(vec)) {//Plete proměnné seznamveci.remove(vec); return vec; } return null; } } public Vec odebervec(string nazevveci) { //Dobrý název for (Vec vec: seznamveci) { if (vec.getnazev().equals(nazevveci)) {//Neplete se seznamveci.remove(vec); return vec; } return null; } } 2012 e-bezpečnost v Kraji Vysočina 28

29 Mezi třídami 1/5 Podobné třídy s rozdílnými rozhraními Třídy, které jsou si podobné uvnitř, ale liší se navenek, je vhodné upravit tak, aby i jejich rozhraní byla podobná či dokonce stejná Posedlost primitivy Nepoužívejte sadu primitiv jako náhradu objektu, který by všechna data sdružoval pod jednou střechou Datové třídy Třídy s instancemi určenými pouze k úschově dat jsou podezřelé; objekt by měl uschovávat data proto, aby s nimi mohl něco dělat Existují i výjimky např. přepravka; tam je ale jasný cíl Shluky dat Vyskytují-li se často pohromadě nějaká data, nejspíš k sobě patří => uvažujte o objektu, který tato data sdruží 2012 e-bezpečnost v Kraji Vysočina 29

30 Mezi třídami 2/5 Odmítnuté vazby Pokud dceřiná třída nepoužívá žádnou funkčnost své rodičovské třídy, je dědičnost nejspíše zbytečná Nevhodné důvěrnosti Jednotlivé třídy by měly mít co nejméně společného Třídy, které toho dělají příliš mnoho spolu bývají příznakem nevhodného návrhu Nevhodné zveřejňování Třída by měla minimalizovat zveřejňování jakýchkoliv informací o svých útrobách, tj. o své implementaci Cíleně minimalizujte zveřejňování takovýchto informací a posilujte tak zapouzdření 2012 e-bezpečnost v Kraji Vysočina 30

31 Mezi třídami 3/5 Líné třídy Každá třída by měl mít pádný důvod pro svoji existenci. Zbytečně definované třídy pouze zvyšují celkovou složitost projektu. Máte-li třídu, která skoro nic nedělá, zamyslete se nad tím, nebylo-li by výhodnější rozpustit její funkčnost mezi ostatní třídy Prostředníci Pokud třída většinu své funkčnosti na někoho deleguje, je v projektu pravděpodobně zbytečná Dávejte si pozor na třídy, které slouží pouze jako obaly na instance jiných tříd a jejich funkcionalitu Prostředníci bývají převlečené závislosti Zřetězení zpráv Dlouhé posloupnosti volání metod a dočasných proměnných potřebné k získání potřebných dat většinou přinášejí skryté závislosti 2012 e-bezpečnost v Kraji Vysočina 31

32 Mezi třídami 4/5 Špatně umístěná metoda Metoda, která intenzivně používá atributy a metody jiné třídy by měla být nejspíš definována ve třídě, jejíž členy používá Rozptýlené změny Vyžaduje-li změna v jedné části třídy nutnost upravit i jinou část, promyslete si, jestli třída neobsahuje dvě relativně nezávislé části, a nebylo-li by ji proto vhodné rozdělit na dvě třídy tak, aby případné změny byly vždy omezeny na jedinou třídu Domino Vyvolá-li změna v jedné třídě kaskádu změn v závislých třídách, je vhodné uvažovat o takové refaktoraci, po níž bude změna omezena pokud možno na jedinou třídu 2012 e-bezpečnost v Kraji Vysočina 32

33 Mezi třídami 5/5 Paralelní hierarchie dědičnosti Občas se stává, že s každou definicí potomka jedné třídy musíte současně definovat i potomka jiné třídy; v takovém případě je vhodné se zamyslet nad tím, zda by nebylo vhodné obě hierarchie dědičnosti nějak sloučit Nekompletní knihovní třída Máme-li knihovnu, jejíž obsah nemůžeme změnit, a potřebujeme-li metodu, která v této knihovně není definovaná, často její definici připíchneme k jiné třídě; vhodnější by ale bylo definovat separátní knihovní třídu, která bude schránkou na takovéto metody Rozmělněné řešení O rozmělněném řešení hovoříme tehdy, je-li k dosažení řešení potřeba příliš mnoho (třeba 5) tříd dané vrstvy; v takovém případě bychom měli uvažovat o úpravě návrhu 2012 e-bezpečnost v Kraji Vysočina 33

34 Vaše jistota na trhu IT Literatura 2012 e-bezpečnost v Kraji Vysočina 34

35 Doporučená literatura 1/7 OOP Naučte se myslet a programovat objektově, Computer Press 2010, ISBN Učebnice pro středoškoláky psaná jako rozhovor Soustředí se na to, jak program navrhnout Není to učebnice jazyka, jazyk je pouze nástroj Učí navrhovat programy podle výše uvedených zásad ICZ, 2011 Rudolf Pecinovský Úvod do OOP 35

36 Doporučená literatura 2/7 Myslíme objektově v jazyku Java Vydala Grada, 2008 ISBN , chystá se nové vydání pro Javu 7 Nepředpokládá žádné předchozí programátorské znalosti Na rozdíl od ostatních učebnic neučí hlavně syntaxi a knihovny, učí především programování Učí navrhovat programy podle výše uvedených zásad a na příkladech ukazuje nebezpečí při jejich nedodržení ICZ, 2011 Rudolf Pecinovský Úvod do OOP 36

37 Doporučená literatura 3/7 M. Fowler: Refaktoring zlepšení existujícího kódu, Grada 2003, ISBN Katalog metod úprav kódu zlepšujících návrh a neměnících funkčnost Velmi dobrý překlad J. Bloch: Java efektivně, 57 zásad sw experta, Grada 2002, ISBN Důležité zásady návrhu dobrého kódu; jedna z nejlepších knih o programování Akceptovatelný překlad K. Beck: Programování řízené testy, Grada 2004, ISBN Představení koncepce + řada doporučení Akceptovatelný překlad, je psána pro Američany Už nejsou v nabídce, je třeba hledat v knihovnách Copyright 2009, Rudolf Pecinovský ICZ 37

38 Doporučená literatura 4/7 Joshua Bloch: Effective Java Second Edition, 2008 Sun Microsystems, Inc. ISBN Prezentace klíčových zásad defenzivního programování spolu s podrobným výkladem možných důsledků porušování těchto zásad Vyhodnocena jako nejlepší kniha o Javě všech dob Autor Javy prohlásil, že kdyby knihu znal, navrhl by podle ní Javu lépe 2012 e-bezpečnost v Kraji Vysočina 38

39 Doporučená literatura 5/7 The CERT Oracle Secure Coding Standard for Java, 2012 Pearson Education, Inc. ISBN Kompendium zásad pro vývoj bezpečných aplikací deklarovaných (a vyžadovaných) firmou Oracle 2012 e-bezpečnost v Kraji Vysočina 39

40 Doporučená literatura 5/7 Vydal Computer Press 2005, ISBN Podrobně vysvětluje řadu konstrukcí, které jinde podrobně česky vysvětlené nenajdete: Parametrizované typy a typové parametry Výčtové typy Anotace Kódování znaků rozšířené sady Unicode Je vyprodaná, ale můžete si ji legálně zdarma stáhnout ve formátu PDF na adrese ICZ, 2011 Rudolf Pecinovský Úvod do OOP 40

41 Doporučená literatura 7/7 Návrhové vzory 33 vzorových postupů pro objektové programování, Computer Press, 2007, ISBN Učebnice návrhu programů pro pokročilejší, předpokládá znalosti zhruba na úrovni modré učebnice Koncipovaná opět jako rozhovor ICZ, 2011 Rudolf Pecinovský Úvod do OOP 41

42 Vaše jistota na trhu IT Rozhraní Implementace Rozhraní Implementace Signatura Kontrakt Dokumentační komentáře Zásady správného programování

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

44 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 Copyright 2006, Rudolf Pecinovský VŠE 03 44

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

46 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 ICZ, 2011 Rudolf Pecinovský Úvod do OOP 46

47 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 ICZ, 2011 Rudolf Pecinovský Úvod do OOP 47

48 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 ICZ, 2011 Rudolf Pecinovský Úvod do OOP 48

49 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í ICZ, 2011 Rudolf Pecinovský Úvod do OOP 49

50 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 Copyright 2006, Rudolf Pecinovský VŠE 05 50

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

52 Vaše jistota na trhu IT Děkuji za pozornost Rudolf Pecinovský mail: ICQ: e-bezpečnost v Kraji Vysočina 52