Přechod
„strukturovaných“
programátorů
k OO programování
Rudolf PECINOVSKÝ
[email protected]
Common 2011
Obsah s odkazy
•
•
•
•
•
•
Common 2011
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
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ě projektu
rozhodovali analytici a programátoři
Při vývoji programů se kladla váha
především na jejich efektivitu
U programátorů byla oceňována
jejich schopnost vyvíjet programy,
s malými HW požadavky
Common 2011
Nyní
Zadání většiny vyvíjených projektů
se v průběhu vývoje neustále mění
Programátorské firmy hledají zákazníky,
kteří si u nich objednají tvorbu projektu
O výsledné podobě projektu
rozhoduje zákazník
Při vývoji programů se klade váha
především na jejich spravovatelnost
a modifikovatelnost
U programátorů je oceňována
jejich schopnost vyvíjet programy,
které je možno rychle a levně přizpůsobovat
neustále se měnícím požadavkům zákazníka
Programování se vyvíjí (3/3)
Dříve
Prvotní úlohou programátora
bylo vymyslet, jak úkol vyřešit
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)
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
Common 2011
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ývoje
po každé drobné změně
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ů se často stává
součástí smlouvy o vývoji programu
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 modifikacemi
vyž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í
• Funkčnost
• Robustnost
• Modifikovatelnost
o
o
Srozumitelnost
Vstřícnost ke změnám
• Spravovatelnost
• Znovupoužitelnost
• Efektivita
• 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
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
o
o
o
vlastnosti (velikost, barva, směr, krása …)
děje (spojení, komunikace, výpočet, …)
události (spuštění, přerušení, ukončení, …)
…
Common 2011
Objekty a zprávy
• Každý objekt má nějaké vlastnosti a schopnosti
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
o
• 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áv
o
Ž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 objekt
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é objekty
o Objekt třídy není ve většině jazyků instancí žádné třídy tříd
o Java a další moderní jazyky umějí pracovat se „zástupcem objektu třídy“
o
• Vzájemné závislosti tříd, resp. objektů daného programu
zná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ět
i zadavatel / zákazník
• Diagram tříd znázorňuje
architekturu systému
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
o
Common 2011
Strukturovaný × OO program
• Strukturovaný program „=“ posloupnost příkazů
o
o
o
o
Analýza: vymýšlejí se postupy
Stavební kameny: procedury/funkce; (proměnné)
Výsledek: většinou samostatný program
Vedlejší cíle: efektivita
• Objektově orientovaný program =
množina objektů, které si posílají zprávy
o
o
o
o
Analýza: definují se účastníci a jejich spolupráce
Stavební kameny: třídy a objekty
Výsledek: velmi často komponenta, služba či jiná část celku
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
o
o
Skrývání implementace
(nikdo nemá mít šanci zjistit, jak je program implementován)
Zvýšení bezpečnosti a robustnosti (nemožnost nekorektního použití)
Usnadnění budoucích modifikací
• Identita
o
o
o
Každá zpráva musí mít svého adresáta, nelze ji posla „do prostoru“
Objekt sám rozhodne, jak na zprávu zareaguje
Důsledek: polymorfizmus – operativní změna typu za chodu programu
(nyní jsem číšník, za chvíli budu obsluhovaný host)
• Skládání
o
o
Objekt může obsahovat jiné objekty
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:
Zrychlují návrh (řešení se nevymýšlí, ale jenom použije)
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ěli
o 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)
o
o
• 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
Zabezpečuje,
aby entita
plnila svoji funkci
Všechno se snaží
maximálně utajit
Definuje, co bude
zbytek programu
o dané entitě vědět
Všem na sebe
všechno řekne
I samotné rozhraní má dvě složky
• Signatura
Specifikuje vlastnosti,
které může zkontrolovat překladač
(názvy, typy, …)
Common 2011
• Kontrakt
Doplňuje další důležité informace,
které však překladač zkontrolovat
nedokáže – o jejich dodržení se
musí postarat programátor
Rozhraní a implementace metody
• Rozhraní – signatura
o
o
o
Jmenuje se blikni
Nemá žádné parametry
Nic nevrací
• Rozhraní – kontrakt
o
o
o
Světlo nejprve „rozsvítí“
Nechá je „svítit“ půl vteřiny
Po půl vteřině je opět „zhasne“
public void blikni()
{
rozsviť();
IO.čekej( 500 );
zhasni();
}
• Implementace
K rozsvícení světla používá svoji metodu rozsviť()
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()
o
o
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 implementaci
Konstrukce dostala název interface –
je to vlastně třída bez implementace
o 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ářů
o
• 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
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é skupiny
volá partnerskou metodu v CPU
o
• Třídy jsou těsně provázané
což má své nepříjemné důsledky:
S každou změnou definice CPU
je třeba změnit definic GUI a naopak
o Každá verze studentského zadání vyžaduje vlastní verzi definice GUI
o Chceme-li po studentech, aby u zkoušky svoji třídu upravili,
musíme příslušně upravit i námi definované GUI
o
Common 2011
Po aplikaci vzoru Most
• Třída CPU implementuje rozhraní ICPU
deklarující tři metody:
o
o
o
RozměrKláves getRozměr()
List<String> getPopisky()
String stisknuto( String label )
• Konstruktor třídy GUI
Dostane instanci of CPU jako parametr
Zeptá se jí na požadovaný rozměr klávesnice
a seznam požadovaných popisků na tlačítcích
o Připraví GUI podle obdržených požadavků
o
o
• Běh programu:
Instance GUI zjistí, jaké tlačítko bylo stisknuto
a zašle instanci CPU zprávu s jeho popiskem
o Instance CPU zjistí, co stisk znamená, a vrátí GUI nový obsah displeje
o
Common 2011
Co jsme tím získali
• GUI může spolupracovat
s různými CPU;
stačí, aby spolupracující CPU
implementovala rozhraní ICPU
• Přiblížíme studentům
vý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
Testování sady programů
• Testovací třída se bude
tvářit, že je zvláštní GUI
• Třída Verze dodá
požadovanou sadu
popisků spolu s testy
definují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
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šinou
jen 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 programu
Aplikací zásad OOP můžeme sémantickou mezeru výrazně zmenšit
1. 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čnosti
o
V řadě případů se definují rovnou třídy oněch účastníků
3. Definují se vlastnosti a schopnosti jednotlivých účastníků
o
o
Jakých stavů mohou nabývat
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
1. 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ý poznatek
okamž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 vzory
o
Použitými v používané aplikaci
 Knihovní třída, Jedináček, Výčtový typ
o
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átka
probraná 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 konstrukce
o
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
Děkuji za pozornost
• Rudolf Pecinovský
mail: [email protected]
ICQ: 158 156 600
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
o
o
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)
Příliš žluťoučký kůň
úpěl ďábelské ódy
Příliš žluťoučký kůň
úpěl ďábelské ódy
Program Keyword
Příliš žluťoučký kůň
úpěl ďábelské ódy
Common 2011
Opakování
Descargar

Document