Prezentace se nahrává, počkejte prosím

Prezentace se nahrává, počkejte prosím

Vaše jistota na trhu IT Zásady OOP pro vývoj bezpečných aplikací Rudolf PECINOVSKÝ 2012 – Vývoj bezpečných aplikací 1.

Podobné prezentace


Prezentace na téma: "Vaše jistota na trhu IT Zásady OOP pro vývoj bezpečných aplikací Rudolf PECINOVSKÝ 2012 – Vývoj bezpečných aplikací 1."— Transkript prezentace:

1 Vaše jistota na trhu IT Zásady OOP pro vývoj bezpečných aplikací Rudolf PECINOVSKÝ 2012 – Vývoj bezpečných aplikací 1

2 Vaše jistota na trhu IT Obsah s odkazy ►Quo vadis, programování? (odkaz)Quo vadis, programování? ► Co je to „bezpečné“? Co je to „bezpečné“? ► Zásady správného a bezpečného programování Zásady správného a bezpečného programování ►Pachy v kóduPachy v kódu ►Rozhraní a implementace (odkaz)Rozhraní a implementace ►Literatura (odkaz)Literatura 2012 – e-bezpečnost v Kraji Vysočina2

3 Vaše jistota na trhu IT Quo vadis, programování? ►Quo vadis, programování? (odkaz dovnitř)Quo vadis, programování? – e-bezpečnost v Kraji Vysočina

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

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

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

7 Jednoduchý příklad nesrozumitelného kódu ►Klasický zápis programátorů v jazyce C ►Zápis, který preferují méně zkušení programátoři ►Dohodněte se na konvencích vyhovujících všem, a ty pak dodržujte 2012 – e-bezpečnost v Kraji Vysočina 7 int znak; do { znak = bufReader.read(); } while (znak != očekávaný); int znak; while ((znak = bufReader.read()) != očekávaný);

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

9 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 9 Common 2011

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

11 Vaše jistota na trhu IT Rozhraní × Implementace ►Rozhraní × Implementace (odkaz dovnitř)Rozhraní × Implementace

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

13 Hlavní zásady ►Dobře navržená architektura výrazně snižuje pravděpodobnost vzniku slabých míst napadnutelných útočníkem ►Zapouzdřete vše, co se mění, abyste měli svobodu při pozdějších úpravách ►Programujte proti rozhraní, ne proti implementaci ►Pro každou třídu ve vaší aplikaci by měl existovat jediný důvod pro její existencí a tím i také pro její případnou změnu ►Rozumně oddělujte data na straně jedné a chování a funkcionalitu na straně druhé ►Kód by měl být co nejjednodušší; čím je kód složitější, tím snáze přehlédneme dírku pro útočníka ● Minimalizujte dostupnost informací použitelných pro napadení ICZ Copyright © 2009, Rudolf Pecinovský 13

14 Maximalizovat soudržnost (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 ►Úkol, který má daná entita na starosti, má vyřešit komplexně a ne jenom částečně ►Je-li úkol složitý, rozdělíme jej na úkoly, které budou řešit samostatné entity a entita zodpovědná za celkové řešení bude jejich práci jenom koordinovat ►http://en.wikipedia.org/wiki/Cohesion_(computer_science)http://en.wikipedia.org/wiki/Cohesion_(computer_science) 2012 – e-bezpečnost v Kraji Vysočina 14

15 Minimalizovat provázanost (coupling) ►Při definici každé entity bychom měli minimalizovat počet entit, které daná entita pro splnění daného úkolu oslovuje ►Používám-li ke splnění svého úkolu jinou entitu, stávám se na ni závislým ● Každá závislost je zárodkem dominového efektu: jakákoliv změna v dané entitě vyžaduje překontrolování všech entit, které jsou na ní závislé ►Zákon bohyně Demeter: Metoda objektu by měla volat pouze metody, které patří ● danému objektu, ● parametrům předaným dané metodě, ● objektům, které sama vytvořila, ● objektům komponent, které obsahuje ►Odkazy ● ● – e-bezpečnost v Kraji Vysočina 15

16 Zapouzdření a rozhraní ►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 16

17 Jednoduchost ►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 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 ►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í ►Programujte proti rozhraní, ne proti implementaci ►Zapouzdřete vše, co se může měnit, abyste měli svobodu při pozdějších úpravách ● Jednou z možností je „schovat“ potenciálně měněný kód za interface ►ISP – Interface segregation principleISP – Interface segregation principle ►http://en.wikipedia.org/wiki/Extreme_programming#Embracing_changehttp://en.wikipedia.org/wiki/Extreme_programming#Embracing_change 2012 – e-bezpečnost v Kraji Vysočina 19

20 OCP – Open/closed 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 ►Ohlídejte, aby nikdo nemohl měnit chování vaší třídy a jejich instancí ►Umožněte zájemcům definovat potomka vaši třídy, který bude lépe vybaven pro řešení některých speciálních situací ►http://en.wikipedia.org/wiki/Open_Closed_Principlehttp://en.wikipedia.org/wiki/Open_Closed_Principle 2012 – e-bezpečnost v Kraji Vysočina 20

21 Jasné rozdělení zodpovědností ►Oddělení zodpovědností (Separation of concerns – SoC) ►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ů ►Každá úloha by měla být přidělená jediné entitě (metodě – třídě – balíčku), která je pak zodpovědná která je pak zodpovědná za jeho vyřešení ● Centrální vedení (armáda, Paleček) ►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_concernshttp://en.wikipedia.org/wiki/Separation_of_concerns ►Toto pravidlo platí i obráceně – viz dále 2012 – e-bezpečnost v Kraji Vysočina 21

22 SRP – Single Responsibility Principle ►Single Responsibility Principle – Princip jediného odpovědného (objektu) ►Pro každou třídu ve vaší aplikaci by měl existovat jediný důvod pro její existencí a tím i také pro její případnou změnu ►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 a všechny schopnosti entity by měly být nasměrování k její realizaci ● Entita by se neměla rozptylovat starostmi o více věcí najednou ►ISP – Interface segregation principle ● Sada specializovaných rozhraní je výhodnější než jedno univerzální ►Při dodržení obou zásad pak každá změna zadání vyžaduje změnu pouze na jednom místě kódu ►http://en.wikipedia.org/wiki/Single_responsibility_principlehttp://en.wikipedia.org/wiki/Single_responsibility_principle 2012 – e-bezpečnost v Kraji Vysočina 22

23 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ě ►Příklad: Jízdenkový automat ● Činnosti:zadat cestu – převzít peníze – vrátit nazpět – vytisknout jízdenku – vydat jízdenku ● Zobecněný úkol: obsloužit zákazníka ►http://en.wikipedia.org/wiki/Abstraction_principle_(programming)http://en.wikipedia.org/wiki/Abstraction_principle_(programming) 2012 – e-bezpečnost v Kraji Vysočina 23

24 DRY - Don’t repeat yourself ►Zopakovaný kód přináší nebezpečí špatné modifikace při budoucích úpravách kódu ● 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 ►Programování stylem copy–paste je cestou do pekel ►Některá řešení existujících duplicit ● Nahradit literály pojmenovanými konstantami ● Opakující se kód „vytknout“ do samostatných metod ● Skupiny opakujících se metod „vytknout“ do společného předka ● Použít návrhový vzor (Služebník, Stavitel, Dekorátor, …) ►http://en.wikipedia.org/wiki/Don%27t_repeat_yourselfhttp://en.wikipedia.org/wiki/Don%27t_repeat_yourself 2012 – e-bezpečnost v Kraji Vysočina 24

25 ICZ Copyright © 2009, Rudolf Pecinovský 25 LSP – Liskov Substitution Principle ►Potomek musí být schopen kdykoliv plnohodnotně vystupovat v roli svého předka (vydávat se za instanci předka) ►Používat dědičnost pouze v případě kdy potomek je speciálním případem předka ● LSP porušuje i potomek, jenž je příliš speciálním případem předka (Obdélník  Čtverec) ►Nevýhodou dědičnosti je porušování zapouzdření ● Metody potomka pracují s daty definovanými v předku ● Potomek musí občas znát implementační detaily předka (metoda setRozměr(int,int) u čtverce) ● Někdy musí dokonce předek znát implementační detaily potomka ►Dávat přednost skládání před dědičností

26 ICZ Copyright © 2009, Rudolf Pecinovský 26 Příklady špatného použití dědičnosti ►Obdélník potomek úsečky, úsečka potomek bodu ►Kruhová výseč je potomkem kruhu ►Kvádr je potomek obdélníku ►Letadlo jako potomek křídla ►Cyklista přeskakující potok po kamenech je potomek žáby ► XObdélník a Terč z modré učebnice ● Zde najdete podrobné vysvětlení, proč je v daném případě použití dědičnosti nevhodné včetně ukázek problémů, k nimž požití dědičnosti v tomto případě vede

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

28 Vaše jistota na trhu IT Pachy v kódu 2012 – e-bezpečnost v Kraji Vysočina28

29 Uvnitř tříd1/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 29

30 Uvnitř tříd2/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 30

31 Uvnitř tříd3/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 31

32 Uvnitř tříd4/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 32

33 Příklad důsledku špatného názvu proměnné 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 33

34 Mezi třídami1/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 34

35 Mezi třídami2/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 35

36 Mezi třídami3/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 36

37 Mezi třídami4/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 37

38 Mezi třídami5/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 38

39 Vaše jistota na trhu IT Literatura ►Literatura (odkaz dovnitř)Literatura 2012 – e-bezpečnost v Kraji Vysočina39

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

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

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


Stáhnout ppt "Vaše jistota na trhu IT Zásady OOP pro vývoj bezpečných aplikací Rudolf PECINOVSKÝ 2012 – Vývoj bezpečných aplikací 1."

Podobné prezentace


Reklamy Google