V minulém článku Baltíka jsem zvládli – kam dál? jsem se snažil vysvětlit, proč se domnívám, že optimálním programovacím jazykem pro výuku programování v kroužku pokročilých je Java. Dnes se pokusím zamyslet nad tím, jak nejlépe s její pomocí učit a jaké zvolit pro počáteční etapy výuky vývojové prostředí.
Nejprve bych chtěl zdůraznit, že se ve svém kroužku pokročilých (na ZŠ) opravdu chystám učit objektově orientované programování (OOP). Opravdoví profesionálové dnes již jinak neprogramují a nevidím ani půl důvodu pro to, abych tuto dovednost před dětmi tajil.
Kdy začít
Objektově orientované programování přináší naprosto nový pohled na problém a z toho vyplývající naprosto odlišný způsob řešení – učeně řečeno: OOP přináší nové paradigma. To, že nás OOP nutí nově přemýšlet, ale ještě neznamená, že by bylo těžké je zvládnout. Těžké je opustit zažité stereotypy a snažit se naučit nové. Pokud ale začneme děti učit tomuto novému přístupu včas, bude jim připadat OOP jako naprosto přirozený způsob řešení problémů a nad našimi historickými postupy se již budou jen usmívat.
Zkušenosti ukazují, že přeškolení zkušeného, klasicky orientovaného programátora na programátora orientovaného objektově trvá 6 až 18 měsíců (čím je zkušenější, tím déle mu změna návyků trvá). Aby děti vzali objektově orientované paradigma hned zpočátku za své, musíme s jeho výukou začít hned od první hodiny. V opačném případě je budeme učit něco, co je budeme za chvíli odnaučovat.
Poznámka: Zeptejte se pana Soukupa, jak se zkušení programátoři vzpírali použít jeho systém grafického programování, i když uznávali, že by pak mohla vzrůst jejich produktivita, a jak děti nezatížené předchozími návyky zvládly tento systém během několika málo lekcí.
Kdybychom to vzali do důsledků, museli bychom přiznat, že již při učení Baltíka vštěpujeme dětem něco, co později zapadne “na smetiště dějin”. Při výuce dětí v našich kroužcích se tento problém naštěstí neprojeví, protože právě to, co je na OOP zásadně jiné, tj. postup při řešení složitých problémů, vstřebávají velmi pomalu (tuto skutečnost jsem ve svých článcích již několikrát zmiňoval), takže se pak většinou ani nemají co odnaučovat.
Samozřejmě, že by bylo lepší začít hned zpočátku objektově, ale objektově orientovaného Baltíka zatím nikdo nevymyslel (i když ten, kterého učíme, by toho moc nepotřeboval), takže ze všech dostupných vývojových nástrojů určených pro vstup do světa programování je klasický Baltík prozatím stále (alespoň podle mne) nejlepší vstupní branou. Navíc dovednosti, které Baltík děti naučil, se jim budou při vstupu do světa OOP velice hodit.
Jak začít
Tady narážíme na velký problém: abychom děti naučili napsat byť jednoduchý objektový program, museli bychom jim toho vysvětlit tolik, že by to většinu z nich přestalo cestou bavit. Musíme na to oklikou.
I já se nyní vydám oklikou a vrátím se na chvíli opět k Baltíkovi (předpokládám, že všichni znáte Baltíka a jeho prostředí natolik, abych je mohl použít jako ilustrační příklad). Jak jistě víte, Baltík má tři základní režimy:
- v kreslícím režimu děti sestavují scény z předem připravených objektů,
- v příkazovém režimu přímo ovládají Baltíka, který ihned vykonává jejich příkazy,
- v programovacím režimu vytvářejí programy, které posléze Baltík vykoná.
Při veškeré výuce přitom využíváme toho, že děti nemusí hned od počátku vytvářet kompletní programy, ale že stačí, když vytvoří pouze drobnou nadstavbu nad předem připravený program simulující Baltíkův svět. Nadstavbu, která upraví chování tohoto programu žádaným směrem (Baltík např. popojde pár kroků a postaví domeček). I když toho děti na počátku vědí ještě málo, už mohou vytvářet relativně efektní (a hlavně pro ně zajímavé) programy.
Když bychom tuto myšlenku přesadili do objektově orientovaného světa, získali bychom její aplikací vývojový nástroj, který by nám umožnil vstupovat do světa OOP také ve třech krocích:
- V prvním kroku (“kreslícím”) by si děti prohlédly strukturu nějakého předem připraveného programu a ujasňovaly by si vzájemné závislosti a interakce jednotlivých tříd a jejich objektů.
- V druhém kroku by si vyzkoušely vytvořit instance instančních tříd a zkusily by s těmito instancemi pracovat – volaly by jejich metody a zkoumaly hodnoty jejich atributů. Hlavním cílem této etapy by mělo být ujasnění si základního vztahu mezi třídou a její instancí (objektem). Děti by si vyzkoušely, že jedna třída může mít řadu instancí. Zjistily by, že nemohou volat metody instancí, dokud žádná instance neexistuje, ale že metody třídy mohou volat i před vznikem prvé instance. Mohly by se dokonce seznámit i se základními projevy polymorfizmu. Také by si mohly ověřit, že není možné vytvářet instance abstraktních tříd ani rozhraní, i když je možné jejich objekty předávat jako parametry.
- V třetím kroku by pak konečně začaly programovat. Protože se však v OOP neobejdeme (na rozdíl od Baltíka) bez relativně složité syntaxe, bylo by vhodné, aby začaly nejprve upravovat existující programy a postupně se na nich naučily vše pro to, aby mohly co nejdříve vytvářet programy vlastní.
Jakmile by jim základy objektově orientovaného přístupu pronikly do krve, mohli bychom se s nimi vydat do dalších oblastí a postupně bychom před nimi odkrývali další a další oblasti světa moderního programování.
Další požadavky na vývojové prostředí
Na vývojové prostředí, které bychom mohli optimálně využít při výuce OOP, bychom kromě podpory výše uvedených tří kroků měli ještě několik dalších požadavků:
- Muselo by být výrazně komfortnější, než mnohde oblíbená dvojice Notepad + Překladač; mělo by v sobě integrovat nástroje pro tvorbu programu, jeho překlad i následné ladění.
- Mělo by být snadno použitelné. Většina vývojových prostředí je totiž optimalizována pro profesionální vývojáře a začátečníci v nich pak zbytečně bloudí.
- Mělo by mít co nejunifikovanější rozhraní, aby se každá jeho část neovládala trochu jinak, a aby se tak minimalizovala námaha potřebná k jeho osvojení.
- Mělo by maximálně usnadňovat opětovné použití částí programu vyvinutých v rámci jiných projektů (jak jsem již říkal, mezi hlavní zásady OOP patří, že programy se nemají znovu vyvíjet, ale znovu použít).
- Mělo by být maximálně uzpůsobené výuce; mělo by podporovat vizualizaci struktury programu i dění v něm (tím nemyslím to, že např. Baltík chodí, ale to, co se děje uvnitř programu), interakci uživatele s programem (např. možnost změny hodnot proměnných za chodu programu, vytvoření další instance apod.) a experimentování.
- Mělo by umožňovat práci v týmu, kdy každý člen skupiny pracuje na své části programu, aby pak na společných schůzkách ladili jejich vzájemné interakce.
- Mělo by být dostupné i studentům, tj. nemělo by být drahé (nejlépe zdarma) a nemělo by mít velké hardwarové nároky.
- Pro výuku menších žáků by mělo být pokud možno lokalizované.
Prostředí BlueJ
Podobné myšlenky napadly i Michaela Köllinga a jeho spolupracovníky v australské Monash University v Melbourne a v Mćrsk Institute dánské University of Southern Denmark v Odense. Výsledkem jejich několikaletého snažení je vývojové prostředí BlueJ, které je nyní dostupné ve verzi 1.2.1. na adrese http://www.bluej.org/ .
Prostředí BlueJ se snaží naplnit všechny výše uvedené požadavky. Ne vždy se mu to sice daří optimálně, ale je prozatím ze všech mně známých prostředí optimu nejblíže. Využívá se proto již na více než 190 universitách a školících centrech po celém světě (viz zde).
Příště vás s ním seznámím podrobněji.
Autor pracuje jako EDU expert ve firmě Amaio Technologies, Inc.
Rudolf Pecinovský
0 comments:
Post a Comment