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
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
Vaše jistota na trhu IT
Quo vadis, programování?
2012 – e-bezpečnost v Kraji Vysočina
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
2012 – e-bezpečnost v Kraji Vysočina
4
Programování se vyvíjí (2/3)
Dříve
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
2012 – e-bezpečnost v Kraji Vysočina
5
Programování se vyvíjí (3/3)
Dříve
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
2012 – e-bezpečnost v Kraji Vysočina
6
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
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
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ý);
2012 – e-bezpečnost v Kraji Vysočina
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
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
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
2012 – e-bezpečnost v Kraji Vysočina
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
2012 – e-bezpečnost v Kraji Vysočina
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
2012 – e-bezpečnost v Kraji Vysočina
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
2012 – e-bezpečnost v Kraji Vysočina
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)
2012 – e-bezpečnost v Kraji Vysočina
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
Vaše jistota na trhu IT
Pachy v kódu
2012 – e-bezpečnost v Kraji Vysočina
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
2012 – e-bezpečnost v Kraji Vysočina
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
2012 – e-bezpečnost v Kraji Vysočina
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
2012 – e-bezpečnost v Kraji Vysočina
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ží
2012 – e-bezpečnost v Kraji Vysočina
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í
2012 – e-bezpečnost v Kraji Vysočina
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
2012 – e-bezpečnost v Kraji Vysočina
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
2012 – e-bezpečnost v Kraji Vysočina
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
2012 – e-bezpečnost v Kraji Vysočina
33
Vaše jistota na trhu IT
Literatura
2012 – e-bezpečnost v Kraji Vysočina
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
Doporučená literatura
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
Doporučená literatura
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
Doporučená literatura
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
Doporučená literatura
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
2012 – e-bezpečnost v Kraji Vysočina
39
Doporučená literatura
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
Doporučená literatura
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
Vaše jistota na trhu IT
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í
2012 – e-bezpečnost v Kraji Vysočina
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
ICZ, 2011 © Rudolf Pecinovský
Ú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
ICZ, 2011 © Rudolf Pecinovský
Ú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
ICZ, 2011 © Rudolf Pecinovský
Úvod do OOP
51
Vaše jistota na trhu IT
Děkuji za pozornost
►Rudolf Pecinovský
mail: [email protected]
ICQ: 158 156 600
2012 – e-bezpečnost v Kraji Vysočina
52
Download

Vývoj bezpečných aplikací - Objektově orientované programování a