43
Přechod „strukturovaných“ programátorů k OO programování Rudolf PECINOVSKÝ rudolf@pecinovsky. cz Common 2011
Přechod „strukturovaných“
programátorů k OO programování
Rudolf PECINOVSKÝ[email protected]
Common 2011
Obsah s odkazy
• Quo vadis, programování?• Základní principy OOP• Rozhraní• Použití rozhraní při návrhu programu• Problémy s přechodem na OOP• Možné řešení: metodika výuky Design Patterns First
Common 2011
Quo vadis, programování?
Common 2011
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í Programy pracovaly samostatně,
navzájem příliš nespolupracovaly Klíčovou úlohou programátora
byl návrh algoritmů a základních datových struktur
Nyní Většina běžných úloh je vyřešena
a řešení jsou dostupná v komponentách či knihovnách
Nové program jsou téměř vždy součástí rozsáhlejších aplikací a rámců
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
Klíčovou úlohou je návrh architektury systému
Common 2011
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ě projekturozhodovali analytici a programátoři
Při vývoji programů se kladla váhapředevším na jejich efektivitu
U programátorů byla oceňovánajejich 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 spravovatelnosta modifikovatelnost
U programátorů je oceňovánajejich 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
Common 2011
Programování se vyvíjí (3/3)Dříve
Prvotní úlohou programátorabylo vymyslet, jak úkol vyřešit
Testy se většinou navrhovalypo dokončení projektu či jeho části
a spouštěly se na závěr před odevzdáním projektu (byl-li čas) Testy navrhovali programátoři
a ověřovali v nich, že program dělá to,
co chtěl programátor naprogramovat Návrh testů byl interní záležitostí
vývojového týmu
Nyní Prvotní úlohou programátora je zjistit,
jestli už někde není problém vyřešen 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ývojepo každé drobné změně Testy se navrhují
ve spolupráci se zákazníkema ověřuje se v nich, že program dělá to,
do po něm zákazník požadoval Návrh testů se často stává
součástí smlouvy o vývoji programu
Common 2011
Shrnutí• Doba programován jako umění skončila,
nastupuje programování jako technologie• Zákazník má jediné kritérium: TOC
Proto dává přednost programům méně dokonalým,ale snadno spravovatelným a modifikovatelným
• Doba, kdy je cena poměrně výkonného počítače srovnatelná s týdenními náklady na programátora, dále upřednostňuje rychlost dodání před rychlostí budoucího zpracování dat
• Časté změny v týmu spolu s častými modifikacemivyžadují psát programy maximálně srozumitelné, tj. tak,aby jejich vývoj mohl být kdykoliv předán některému z kolegů
Common 2011
Priority současného programování
• Program nemusí být rychlý, stačí, když jej zákazník považuje za dostatečně rychlý
• Napsat program, kterému rozumí počítač, umí každý trouba.Dobří programátoři píší programy, kterým rozumí lidé.Marin Fowler, Refactoring
• Funkčnost• Robustnost• Modifikovatelnost
o Srozumitelnosto Vstřícnost ke změnám
• Spravovatelnost• Znovupoužitelnost
• Efektivita
Common 2011
Základní principy OOP
Common 2011
Všechno je objekt
• První myšlenky se objevily v jazyku Simula, což je jazyk vyvinutý pro programování simulací
• Později chytrým došlo: Každý program je simulací reálného či virtuálního světa
• Ve světě lze vše považovat za objekt => má-li být simulace přesná, musí umět s objekty pracovat
• Myšlenku, že vše je objekt, OOP rozšiřuje na vše, co můžeme označit podstatným jménem …
• => jako objekt jsou v OO programech zpracovávány i o vlastnosti (velikost, barva, směr, krása …)o děje (spojení, komunikace, výpočet, …)o události (spuštění, přerušení, ukončení, …)o …
Common 2011
Objekty a zprávy• Každý objekt má nějaké vlastnosti a schopnosti
o Vlastnosti popisují okamžitý stav objektu,jejich hodnoty se ukládají do konstant / proměnných objektu
o Schopnosti objekt demonstruje tím, že je schopen odpovědět na odpovídající zprávu
• V reálném světě jsou všechny děje důsledkem toho,že spolu objekty navzájem interagují – jeden objekt působí na druhý a ten na to reaguje
• Interakce objektů se v OO programech simuluje zasíláním zprávo Židle zašle podlaze zprávu o své váze, podlaha ji odpoví, jestli ji unese
• Část kódu definující reakci objektu na zaslanou zprávu nazýváme metoda
Common 2011
Objekty a třídy• Některé jazyky (C++, C#, Java) sdružují objekty do tříd a
označují pak jednotlivé objekty dané skupiny jako instance příslušné třídy
• Třídu můžeme označit podstatným jménem => podle předchozí zásady je tedy třída objekto Třída je zvláštní druh objektu, který umí na požádání vytvořit svoji
instanci (třída je „forma“ na vytváření svých instancí)o Třídy jsou jediné objekty, jež umějí vytvářet jiné objektyo Objekt třídy není ve většině jazyků instancí žádné třídy třído Java a další moderní jazyky umějí pracovat se „zástupcem objektu třídy“
• Vzájemné závislosti tříd, resp. objektů daného programuznázorňujeme v diagramu tříd, resp. v diagramu objektů
• Oba diagramy jsou součástí sady diagramů označované jako grafický jazyk UML (Unified Modeling Language)o V UML vypadají oba výše zmíněné diagramy velmi podobně
Common 2011
Diagram tříd jednoduchého projektu• Při pohledu na UML
klasicky orientovaného programátora hned napadne: „Ten obrázek můj problém nevyřeší“
• Obrázek však umožní vyjadřovat se v pojmech, kterým bude rozuměti zadavatel / zákazník
• Diagram tříd znázorňuje architekturu systému o Umožní rozdělit problém na
jednotlivé části a výrazně tak urychlit vývoj
o Umožní udržovat povědomí o vzájemných souvislostech
Common 2011
Strukturovaný × OO program• Strukturovaný program „=“ posloupnost příkazů
o Analýza: vymýšlejí se postupyo Stavební kameny: procedury/funkce; (proměnné)o Výsledek: většinou samostatný programo Vedlejší cíle: efektivita
• Objektově orientovaný program =množina objektů, které si posílají zprávyo Analýza: definují se účastníci a jejich spolupráceo Stavební kameny: třídy a objektyo Výsledek: velmi často komponenta, služba či jiná část celku o Vedlejší cíle: přehlednost, modifikovatelnost, znovupoužitelnost
• OOP vede k výrazně jinému způsob uvažovánínež klasické strukturované programovánío Kurzy, které neučí tento nový způsob uvažování
neučí OO programování ale pouze kódování v OO jazyce
Common 2011
Základní pilíře OOP• Zapouzdření (kód je pohromadě se zpracovávanými daty)
o Skrývání implementace(nikdo nemá mít šanci zjistit, jak je program implementován)
o Zvýšení bezpečnosti a robustnosti (nemožnost nekorektního použití)o Usnadnění budoucích modifikací
• Identitao Každá zpráva musí mít svého adresáta, nelze ji posla „do prostoru“o Objekt sám rozhodne, jak na zprávu zareagujeo Důsledek: polymorfizmus – operativní změna typu za chodu programu
(nyní jsem číšník, za chvíli budu obsluhovaný host)• Skládání
o Objekt může obsahovat jiné objektyo Dědičnost – speciální případ, při němž s objektem převezmu i jeho rozhraní
Omezuje duplicity v kódu Nebezpečí špatného použití (narušuje zapouzdření) Dědičnost používáme, až jen když jsou ostatní řešení nešikovná
• Používání návrhových vzorůo Proč bych měl vymýšlet něco, co už je vymyšlené, a je to vymyšlené dobře
Common 2011
Návrhové vzory – Design Patterns
• Programátorský ekvivalent matematických vzorečků• Do návrhových vzorů se nedosazují čísla, ale objekty a třídy• Výhody:
o Zrychlují návrh (řešení se nevymýšlí, ale jenom použije)o Zkvalitňují návrh – jsou ověřené, takže výrazně snižují
pravděpodobnost potenciálních chyb typu na něco jsme zapomnělio Zjednodušují a zpřesňují komunikaci mezi členy týmu
(větou, že diskriminant je záporný, řeknu znalým jednoduše řadu věcí, které bych musel jinak složitě vysvětlovat)
• Znalost návrhových vzorů patří k povinné výbavě současného objektově orientovaného programátora,a proto by se měly učit co nejdříve
Common 2011
Rozhraní
Common 2011
Trocha mytologie
• Janus římský bůh vchodů, dveří, počátku a konce
• Měl dvě tváře: jedna hleděla do budoucnosti, druhá do minulosti
• I program má dvě tváře:
Rozhraní ×Implementace
Common 2011
Rozhraní Implementace
Definuje, co budezbytek programu o dané entitě vědět Všem na sebe všechno řekne
Zabezpečuje, aby entita plnila svoji funkciVš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, …)
• KontraktDoplňuje další důležité informace, které však překladač zkontrolovat nedokáže – o jejich dodržení se musí postarat programátor
Common 2011
Rozhraní a implementace metody
• Rozhraní – signaturao Jmenuje se bliknio Nemá žádné parametryo Nic nevrací
• Rozhraní – kontrakto Světlo nejprve „rozsvítí“o Nechá je „svítit“ půl vteřinyo Po půl vteřině je opět „zhasne“
• Implementaceo K rozsvícení světla používá svoji metodu rozsviť()o Půlvteřinové svícení zabezpečí pozastavením programu
pomocímetody čekej() třídy IO, které předá počet milisekund čekání
o Zhasnutí realizuje zavoláním své metody zhasni()
public void blikni(){rozsviť();IO.čekej( 500 );zhasni();}
Common 2011
interface – formalizovaný zápis rozhraní• Programujte proti rozhraní, ne proti implementaci
(Program to an interface, not an implementation)• Java zavedla speciální konstrukci umožňující deklarovat
rozhraní bez jakékoliv zmínky o implementacio Konstrukce dostala název interface –
je to vlastně třída bez implementaceo Signatura rozhraní je dána deklaracemi metod
a statických konstant (konstanty se nedoporučuje používat)o Kontrakt je (stejně jako u standardních tříd)
definován prostřednictvím dokumentačních komentářů• interface nemá implementaci => nemůže mít instance
o Za jeho instance se vydávají instance tříd,které se veřejně přihlásí k implementaci daného rozhraní
• S nadsázkou můžeme říci, že celé moderní programování je o tom, jak co nejlépe využít možností rozhraní
Common 2011
Složitější projekt
Common 2011
Použití rozhranípři návrhu programu
Common 2011
Oddělit části kódu, jež se mohou měnit• Jakmile používám nějakou část programu, tak na ní závisím
(přizpůsobovat se musí vždy volající, ne volaný)• Každá změna kódu může ovlivnit části,
které na upravené části závisí;jejich úprava může ovlivnit další části atd.
• Každá změna kódu hrozí dominovým efektem• Dominový efekt mohu zastavit
oddělením měněné části od okolního kódu• Jedním z nejlepších postupů
je vložit mezi obě části rozhraní• Příklad: Kalkulačka
Common 2011
Klasicky navržená kalkulačka• Klasický přístup
o Odděluje se návrh CPU and GUI;– Třídu GUI navrhuje vyučující– Třídu CPU navrhují studenti
o Stisk tlačítka z každé skupinyvolá partnerskou metodu v CPU
• Třídy jsou těsně provázanécož má své nepříjemné důsledky:o S každou změnou definice CPU
je třeba změnit definic GUI a naopako Každá verze studentského zadání vyžaduje vlastní verzi definice GUIo Chceme-li po studentech, aby u zkoušky svoji třídu upravili,
musíme příslušně upravit i námi definované GUI
Common 2011
Po aplikaci vzoru Most• Třída CPU implementuje rozhraní ICPU
deklarující tři metody:o RozměrKláves getRozměr()o List<String> getPopisky()o String stisknuto( String label )
• Konstruktor třídy GUIo Dostane instanci of CPU jako parametro Zeptá se jí na požadovaný rozměr klávesnice
a seznam požadovaných popisků na tlačítcícho Připraví GUI podle obdržených požadavků
• Běh programu:o Instance GUI zjistí, jaké tlačítko bylo stisknuto
a zašle instanci CPU zprávu s jeho popiskemo Instance CPU zjistí, co stisk znamená, a vrátí GUI nový obsah displeje
Common 2011
Co jsme tím získali
• GUI může spolupracovat s různými CPU; stačí, aby spolupracující CPUimplementovala rozhraní ICPU
• Přiblížíme studentůmvýznam a použití rozhraní
• Ukážeme, že tvůrce GUI nemusíznát spolupracující CPU předem, instance GUI se ji může dozvědět až při svém zrodu
• Můžeme do CPU svobodně přidávat další a další funkce,aniž bychom museli jakkoliv upravovat třídu GUI
• Můžeme připravit automatické testy
Common 2011
• Testovací třída se budetvářit, že je zvláštní GUI
• Třída Verze dodápožadovanou sadupopisků spolu s testydefinujícími požadované reakce na stisk kláves
• Rozhraní ICPU rozšíříme o metodu vracejícípořadí řešeného zadáníint getZadání()
• Můžeme přidat značkovací rozhraní IGUI,jež budou implementovat třídy, které se chtěji vydávat za GUI
Testování sady programů
Common 2011
Problémy s přechodem na OOP
• Shrnutí či téma
Common 2011
Nevýhody klasicky orientovaných kurzů• Řada kurzů zmíní na počátku letmo základní zásady OOP,
avšak následně se soustředí především na syntaxi jazyka a demonstraci probíraných konstrukcíprostřednictvím jednoduchých AHA programůo AHA příklad je superjednoduchý demonstrační příklad,
po jehož analýze si student řekne: „Aha, takto to funguje“• Mezi demonstrací principu
na jednoduchém AHA příkladu typu Hello World a použitím vysvětlovaného principu v reálné situaci bývá často dlouhá a strastiplná poznávací cesta
• I když kurzy tvrdí, že učí OOP, učí ve skutečnosti většinoujen procedurální programování v OO jazyce, takže namísto OO paradigmatu učí jenom kódování v OO jazyce
Common 2011
Nevýhody předčasné koncentrace na kód
• Takovýto „bottom-up“ přístup vychovává návyky,které následně ztěžují komunikaci se zákazníky
• Takto vychovaný programátor začne hned po obdržení zadání přemýšlet, jak by program zakódoval a hovoří v termínech svého kódu
• Mezi ním a zákazníkem vznikne sémantická mezera
Common 2011
Postup vývoje OO programuAplikací zásad OOP můžeme sémantickou mezeru výrazně zmenšit1. Definují se základní požadované funkce programu
specifikují se případy užití (use cases)2. Definují se účastníci, tj. objekty,
které vystupují při realizaci požadované funkčnostio V řadě případů se definují rovnou třídy oněch účastníků
3. Definují se vlastnosti a schopnosti jednotlivých účastníkůo Jakých stavů mohou nabývato Jakým zprávám budou rozumět a umět na ně reagovat
Až sem bývá zákazník schopen komunikovat a případněmodifikovat špatně pochopné zadání či návrh realizace• Definuje se způsob (algoritmus), jak bude vše realizováno
o Tady už se zákazník většinou ztratí
Common 2011
1. Případy užití
Common 2011
2. Účastníci
Common 2011
3. Vlastnosti a schopnosti
Common 2011
Děti jsou na tom lépe
• 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ý poznatekokamžitě podvědomě propojí s tím, co zná
• Programátor poslouchající výklad o OOP podvědomě převádí vysvětlované termíny do paradigmatu, v němž je doma;při tomto převodu dochází k výrazné desinterpretaci pojmů
Common 2011
Možné řešení: metodika výuky Design Patterns First
Common 2011
Interaktivní režim• Začíná v interaktivním režimu prací s objekty a třídami • Využívá možnosti používaného prostředí
definovat i v interaktivním režimu vlastní třídu• Již v interaktivním režimu seznamuje
s konstrukcí interface včetně dědičnosti rozhranía učí její význam v programech
• Již v interaktivním režimu seznamuje s návrhovými vzoryo Použitými v používané aplikaci
Knihovní třída, Jedináček, Výčtový typo Umožňujícími řešení řešených problémů
Služebník, Prostředník, Pozorovatel, • Poté se přejde do klasického textového režimu,
v němž se znovu projde látkaprobraná před tím v interaktivním režimu
Common 2011
Ranní ptáče
• Respektuje pedagogické pravidlo ranního ptáčete (early bird), tj. začíná se výukou nejdůležitějších principů
• Od počátku studenti pracují na relativně složitých projektech, u nichž přidávají či zdokonalují nějakou jejich funkci anebo je používají jako knihovnu
• Studenti si přitom osvojí postup, při němž každou úlohu řeší nejprve na vyšší úrovni abstrakce, a teprve pak přejdou ke kódu
• Od samého počátku se seznamují s nejdůležitějšími principy včetně konstrukce interface a návrhových vzorů
• Poté zvládnutí interaktivního režimu začneme s psaním kódu, při němž se veškerý předchozí výklad ještě jednou zopakuje
Common 2011
Tvorba kódu• Jakmile začnou studenti tvořit vlastní kód,
velmi záhy se začnou učit,kdy, proč a jak navrhnout vlastní interface
• Před výkladem algoritmických konstrukcíučí objektové techniky nahrazující tyto konstrukceo Návrhový vzor Stav
• Algoritmické konstrukce jsou probírány až po objektových• Před výkladem dědičnosti je probrán a procvičen
návrhový vzor Dekorátor• Dědičnost tříd je zavedena jako automatizovaná aplikace
návrhového vzoru Dekorátor
Common 2011
Common 2011
Pgm Používaná písma a objekty
• Pgm Příliš žluťoučký kůň úpěl ďábelské ódy (Demi)o 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)
o Příliš žluťoučký kůň úpěl ďábelské ódy (Franklin Gothic Book)o Příliš žluťoučký kůň úpěl ďábelské ódy (Comic Sans MS)o 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
Příliš žluťoučký kůň úpěl ďábelské ódy
Příliš žluťoučký kůň úpěl ďábelské ódy
Common 2011
