takze inline...
Takze mal som konecne cas a precital som celu temu a aj zadanie som cele spravil a prisiel som na to, ze:
1. pouzivat BlueJ nie je zle, kazdopadne sa s nim malo robi a podla mna to nebude mat nejaky pozitivny vyznam. Ked clovek nie je spomaleny, tak aj tak pochopi o com su objekty a aspon bude vediet syntax. Takto si zvykne klikat a moze mu skor odist pointa objektov , resp. skor mu ujde uplne syntax a tazko sa mu bude pisat (zvlast ked ako niektori tu spominali ze odflakli cecko). Podla mna kto chcel tak pochopil aj predtym a kto nie tak ani teraz.
bluej pouzivame na uvod - v principe ide o objects first approach. ludia maju problem pochopit, o com tie objekty su - je to aj moj pripad - po absolvovani oop za mojich cias som nebol objektovy programator. necitil som potrebu, nevidel som vyhody. okrem toho sa snazime robit trosku interaktivne cvika, aj ked tu interaktivitu skryvame - nie je podstatne, aby studaci vedeli, ze ako sa vytvori okno, ako sa nakresli v skutocnosti obdlznik. ale ked mu zmenia farbu, tak to vidia, ze sa zmenila. a nie si abstraktne predstavovat farbu a jeho rozmery pri vypisovani tychto informacii na obrazovku.
nevidim dovod, preco by mu mala pri klikani odist pointa objektov, pretoze bluej je prave o tom priblizeni oop paradigmy, kde vidis (aj klikaci) rozdiel v tom, co je to trieda a co je to objekt alebo kde je trieda a kde je objekt alebo z coho vznikaju instancie a kolko ich moze byt.
co sa syntaxe tyka, tej si uziju trosku neskor. metody budu implementovat tak ci tak, instancie v triedach budu vytvarat tiez. ozajstne programovanie si vsak uziju trosku neskor. osobne vidim v tomto pristupe vyhodu a v podstate vy ste boli prvi, na ktorych sme kus menili osnovu cviceni. vtedy to boli len prve zablesky, ale teraz to uz od dokonalosti nema daleko :-)))
2. implementacne je to urcite lepsie robene ako ked clovek to sam robil. Sak co by sme sa cudovali ked sa na tom zucastnili Poruban a Vaclavik. Je vsak velmi smutne ze az po x rokoch co sa ucit ten predmet a stale ho ucia viacmenej ti isti ludia tak nebol nikto schopny doteraz spravit normalne zadanie ako je aspon teraz.
nuz - toto zadanie je prave o objektoch. ked sa robili este klikacie aplikacie, tak to velmi o objektoch nebolo, ale skor o biznise. aj preto vidiet rozdiel u vas - studentov - pretoze sa uz viete kus viac pozerat na svet objektovo.
poruban s vaclavikom sa az tak na tej implementacii nepodielali, ale vdaka nim doslo ku zmene - teda aspon u mna. tiez mi chvilu trvalo, kym som pochopil, ze sposob vyucby, ktory tu bol dlhe roky prezentovany, nie je o objektovom programovani. pomohli ale velmi pri vzniku cvik (pripomienkovacie konanie) ako aj pri diskusii o zadani a jeho tvare. myslienka textovky je prebrata od pecinovskeho, kde som sa nechal inspirovat napadom (nejedna sa o kopiu 1:1 - pecinovsky vychadza z knihy Objects first with java (
http://www.bluej.org/objects-first/)), ale zvysok je viacmenej vlastny pohlad na zadanie, ako aj skusenosti s textovkami na 8bitoch :-) kazdopadne - obaja pomohli velmi vela pre dosiahnutie sucasnej tvare cviceni a rozpravame sa na tuto temu pravidelne v nepravidelnych intervaloch
3. zadanie je celkovo dobre spravene, akurat ze ten load je debilne spraveny. Neviem teda ci je chyba u mna, ale tak ako keby na to nebolo myslene a clovek musi doplnovat naviac metody do tried, lebo proste chybaju v rozhraniach.
myslis prikaz LOAD? co ti kde chyba?
na druhej strane - niekde su medzery zamerne - tyka sa to asi najma historie. medzery cisto len kvoli tomu, aby sa s tym clovek trosku popasoval a porozmyslal, ze ako s tym pohnut (napriklad prikaz INVENTAR).
4. co sa tyka Design Patterns, tak tazko vobec rozmyslat o tom, zeby sa mali ucit priebezne. To je absolutne nerealne. Ta clovek ani nevie dokopy pointu OOP a hned sa zacne ucit DP? to je co za nezmysel? taktiez si DP omnoho lepsie zapameta ak uz ma daco odkodene a si vie porovnat ze bez DP to robil jak tlk a kopec veci bolo zbytocne tazsich.
neviem, ze k comu patri tato vycitka o priebeznych DP. ked sa pozries do zadania, su tam v podstate tri: singleton, command, library method. singleton budu riesit pri historii - sam si o nom povedal, ze je bezproblemovy. command riesia od vytvorenia prveho prikazu, len nebol pomenovany, ze je to DP. podobne library method - o tom sa uz dalo mozno hovorit pri statickych metodach a premennych - pouzivaju ich normalne pri praci so standardnym vstupom a vystupom. opat len nieco dostanu, co sa da pomenovat. samozrejme - vsetky DP sa prebrat nemozu/nestihnu, ale lahky vyber sa da spravit a rovno aj ukazat jeho pouzitie v zadani. ci?
5. nechcem sa opakovat ale tak ten BlueJ nie je vobec vyuzity jeho potencial. BlueJ dokaze generovat kod a kopec inych veci, ktore vobec neboli spomenute na cvikach. Cital som jednu knihu ked typek pouzival BlueJ a to bolo tak brutalne robene ze do takmer konca vobec nepouzival dedicnost, dokonca ani operatory + -, ... ale zase rozhrania takmer uplne od zaciatku a to bolo realne pouzitie rozhrani vratane dedicnosti. Potom cloveku prisli rozhrania ako uplne prirodzena vec, co po tomto zadani neviem ci tak celkom bude. (ale urcite viac ako pred 2 rokmi jak sme my mali OOP)
generovanie kodu z bluej - na buduci rok, ked ho budeme mat, tak prave tie sablony pre novu triedu a metodu odstranime, lebo su uplne zbytocne, matuce (kvoli exampleMethod(), example variables, ...)
kniha od typka je fajna. aj jeho pohlad na svet bez dedicnosti je fajny (v principe dedicnost tiez riesime len prostrednictvom abstraktnych tried). a do tretice - aj vdaka typkovi pouzivame bluej na cvikach (boli pokusy o object test bench vo vizualnom studiu, ale slabo to ti inzinieri odkukali :-P) podobne ako typek neriesime pretazovanie operatorov a tiez by som nebol proti rozhraniam pred dedicnostou (je napad na trosku ine zadanie, ale to je len v stadiu priprav). a ci budu rozhrania jasnejsie - nuz - urcite budu jasnejsie, ako kedysi pred troma rokmi...
6. neviem ci to bolo na cvikach vysvetlovane (zrejme urcite) ale v zadani vyslovene chybaju napriklad odskusanie prekryvania a pretazovania...
na cvikach sa nevysvetluje - na cvikach sa precvicuje (nie nadarmo slovo cvicenie ma zaklad od slova cvicit a nie prednasat/vysvetlovat). prekryvanie a pretazovanie sme riesili v cvikach s bluej-om. ak mas napad, kde sa daju pouzit, tak nadhod - na materialoch sa pracuje stale.
P.S. s tym backpackom nie je nutne pridavat ziadne metody naviac oproti tym z Interfacu, dasa to robit aj inak a ide to (mam to tak spravene) kus tam ale treba spravit taky mensi hack.
P.S.2 Chcel by som sa spytat ako je to s tym 12 cvikom, lebo tam nieje zatial nic, len daky Unit Testy. To znamena co? Text bude este doplneny a testy sa budu robit vsetci rovnako, alebo sa len vysvetli princip a kazdy robi sam? Myslim ze by malo zmysel robit spolocne, sak vsetci pouzivaju interfacy a teda sa daju testy pouzit hromadne. Dalsia vec je ze sa bude pouzivat JUnit 3, ci 4?
budu spolocne. toto cviko trosku unika, pretoze bola trochu ina predstava, ale co uz - nevychadza nam to. na druhej strane - nesedi jeho zaradenie, ale to uz teraz nevyriesime - TDD sa robi pred samotnou implementaciou - tu ich riesime na konci, co naburava tento princip. takze - testy budu, spolocne (podobny navod ako ostatne cvika), ale v buducnosti budu rozbite na tie miesta, kde sa riesi implementacia testovanych tried.
diky za komenty/pripomienky a hlavne vlastny nazor. mozno sa pozname aj z videnia (kedze porubanovec asi nie je tvoje priezvisko, ale ucil som vo vasom rocniku par skupin). ak mas nejake napady na ozivenie, tak tiez napis - odkukavat a inspirovat sa treba. sice ty uz tu zmenu nezazijes, ale mozno budes aspon veselsi, ze si prispel ku zlepseniu veci
p.s. inac sprtnem aj ja trochu - z tych reakcii vyplyva, ze kvalitu predmetu hodnotite (nie len ty) na zaklade cviceni, aj ked predmet nie je tvoreny len cvikami, ale aj prednaskami. cvika sa snazia len reflektovat to, co je odprednasane a ponuknut sposob otestovania/overenia nadobudnutych znalosti...