Vývoj bezpečných aplikací

Vaše jistota na trhu IT

Vývoj bezpečných aplikací Rudolf PECINOVSKÝ [email protected] 2012 – e-bezpečnost v Kraji Vysočina

1


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


Quo vadis, programování?


3

Programování se vyvíjí (1/3) Dříve

Nyní

Řada běžných, často se vyskytujících úloh stále čekala na vyřešení

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


4


Nyní

Metodika vývoje programů počítala s pevným zadáním

Zadání většiny vyvíjených projektů se v průběhu vývoje neustále mění

Zákazníci hledali firmu, která jejich projekt naprogramuje

Programátorské firmy hledají zákazníky, kteří si u nich objednají tvorbu projektu

O výsledné podobě projektu rozhodovali analytici a programátoři

O výsledné podobě projektu rozhoduje zákazník

Při vývoji programů se kladla váha především na jejich efektivitu

Při vývoji programů se klade váha především na jejich spravovatelnost a modifikovatelnost

U programátorů byla oceňována jejich schopnost vyvíjet programy, s malými HW požadavky

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


5


Nyní

Prvotní úlohou programátora bylo vymyslet, jak úkol vyřešit

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


6


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

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á


8

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

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ý);


10

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ž 100 000 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

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 2011

12

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 12 – 18 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


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

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 ● http://en.wikipedia.org/wiki/Cohesion_(computer_science)

► 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 ● http://en.wikipedia.org/wiki/Coupling_(computer_programming) ● S konkrétními pravidly přichází zákon bohyně Demeter http://en.wikipedia.org/wiki/Law_of_Demeter 2012 – e-bezpečnost v Kraji Vysočina

15

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 ● http://en.wikipedia.org/wiki/KISS_principle ● Často se také formuluje : vytvoř to nejjednodušší, co ještě bude fungovat ● http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html ● http://en.wikipedia.org/wiki/Principle_of_good_enough

► 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 ● http://en.wikipedia.org/wiki/YAGNI


16

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 ● http://en.wikipedia.org/wiki/Encapsulation_(computer_science) ● http://en.wikipedia.org/wiki/Information_Hiding

► 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, …) ● http://en.wikipedia.org/wiki/Design_Patterns ● http://en.wikipedia.org/wiki/Interface_(object-oriented_programming) ● http://en.wikipedia.org/wiki/Interface_(computer_science) 2012 – e-bezpečnost v Kraji Vysočina

17

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šší ● http://c2.com/cgi/wiki?CodeForTheMaintainer

► 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 ● http://en.wikipedia.org/wiki/Principle_of_least_astonishment ● http://en.wikipedia.org/wiki/Don%27t_Make_Me_Think


18

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 ● http://en.wikipedia.org/wiki/Open_Closed_Principle

► 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í ● http://en.wikipedia.org/wiki/Extreme_programming#Embracing_change


19

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 ● http://en.wikipedia.org/wiki/Single_responsibility_principle

► 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 ● http://en.wikipedia.org/wiki/Separation_of_concerns


20

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 ● http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

► 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ě ● http://en.wikipedia.org/wiki/Abstraction_principle_(programming)


21

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


Pachy v kódu


23

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


24

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


25

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

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


27

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

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ží


29

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í


30

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


31

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


32

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


33


Literatura


34

Doporučená literatura

1/7

►OOP – Naučte se myslet a programovat objektově, Computer Press © 2010, ISBN 978-80-251-2126-9. ►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


2/7

► Myslíme objektově v jazyku Java ► Vydala Grada, 2008 ISBN 978-80-247-2653-3, 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


3/7

► M. Fowler: Refaktoring – zlepšení existujícího kódu, Grada 2003, ISBN 80-247-0299-1

● 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 80-247-0416-1

● 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 80-247-0901-5

● 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


4/7

► Joshua Bloch: Effective Java™ Second Edition, © 2008 Sun Microsystems, Inc. ISBN 0-321-35668-3 ► 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


5/7

► The CERT ® Oracle ® Secure Coding Standard for Java ™, © 2012 Pearson Education, Inc. ISBN 0-321-80395-7 ► Kompendium zásad pro vývoj bezpečných aplikací deklarovaných (a vyžadovaných) firmou Oracle


39


5/7

► Vydal Computer Press 2005, ISBN 80-251-0615-2 ► 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 http://knihy.pecinovsky.cz/java5novinky ICZ, 2011 © Rudolf Pecinovský

Úvod do OOP

40


7/7

►Návrhové vzory – 33 vzorových postupů pro objektové programování, Computer Press, © 2007, ISBN 978-80-251-1582-4 ►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


Rozhraní × Implementace ► Rozhraní × Implementace ► Signatura × Kontrakt ► Dokumentační komentáře ► Zásady správného programování 159–176

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í


43

Rozhraní

Implementace

Definuje, co bude zbytek programu o dané entitě vědět

Zabezpečuje, aby entita plnila svoji funkci

Všem na sebe všechno řekne

Všechno se snaží maximálně utajit

I samotné rozhraní má dvě složky ► Kontrakt

► Signatura

Doplňuje další důležité informace, které však překladač zkontrolovat nedokáže – o jejich dodržení se musí postarat programátor

Specifikuje vlastnosti, které může zkontrolovat překladač (názvy, typy, …)

Copyright © 2006, Rudolf Pecinovský

VŠE – 03

44

Příklad – rozhraní ITvar v projektu Tvary

Copyright © 2006, Rudolf Pecinovský

VŠE – 03

45

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

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

47

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

48

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

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

Použití v projektu


Úvod do OOP

51


Děkuji za pozornost

►Rudolf Pecinovský mail: [email protected] ICQ: 158 156 600 2012 – e-bezpečnost v Kraji Vysočina

52

Vývoj bezpečných aplikací

Recommend Documents