PB162:Prednaska

Z FI WIKI
Přejít na: navigace, hledání

Tato stránka obsahuje komentáře k přednáškám z PB162

Všeobecné

Možná bych se snažil používat anglické identifikátory, aby si na to studenti zvykli hned od začátku.

Ano, a budeme to tak dělat a požadovat i v zadání úloh.

První přednáška

[1]

dal by se doplnit seznam vsech novych syntaktickych konstrukci v Java 1.5 (jsou tam vetsi zmeny nez jen klicove slovo enum)

[2]

Zdrojový kód (Source Code) knihoven z Java Core API se nalézá v archivu src.zip. (ne src.jar)

[3]

Doplnil bych javaws

[4]

Doplnil bych u javah info, ze to souvisi s JNI

[5]

Odkaz na ulohu bych uplne zrusil, dal bych je zvlast do prislusne slozky v IS

Druhá přednáška

[6]

"Kromě celých čísel int nabízí Java celou řadu dalších primitivních datových typů. Primitivní typy jsou dané napevno, programátor je jen používá, nedefinuje. Podrobněji viz ???" - Chybi tu asi odkaz

"Objektovými typy v Javě jsou třídy (class) a rozhraní (interface)." - Asi to nema cenu na tomto miste rozvadet, ale objektovym typem jsou i pole. Dokonce se da napsat

int[] pole = new int[10]; Object o = pole;

[7]

"blíže viz podrobný rozbor na FIXME" // to fixme je asi chybejici odkaz

[8]

"regulují pdobně" // preklep

[9]

"Pozn.: I když metoda něco vrátí, my to nemusíme použít, ale je to trochu divné..."

Rekl bych, ze to nemusi byt na prvni pohled jasne, co tim myslis. Mozna by neuskodil maly prikladek.

[10]

Tady bych doplnil nekolik veci:

Jak je psát a co s nimi lze dělat?

  • jmenují se stejně jako příslušná třída
  • nemají návratový typ (ani void - to už vůbec ne!!!)
  • mohou mít parametry
  • mohou volat jiný konstruktor nebo konstruktor rodičovské třídy - ale jen jako svůj první příkaz

// ad 1) ony vlastne nemaji nazev, a jejich sytnaxi mas na predchozim slajdu, ale tahle by to mohlo byt srozumitelnejsi. Nebo by se dala pouzit formulace "Místo jejich jména se uvádí jméno dané třídy"

// ad 4) Proc musi byt volani konstruktora predka jako prvni vyraz konstruktoru chapu, proc totez plati i pro volani jinych konstruktoru stejne tridy uz ne. Ale je to tak.

[11]

Tady bych doplnil upozorneni:

"Řetězení volání metod je nutné používat opatrně, neboť může kód značně znepřehlednit!"

(Dokonce i Honza za mnou prisel s tim, ze mu nefunguje kus kodu v DOM4J, a problem byl v tom, ze pouzival zretezeni a volal urcitou metodu na jinem uzlu nez chtel. Jak to pak asi dokaze zamotat hlavu studentum treba ve znackovacich jazycich...)

Třetí přednáška

[12]

"Vzorový zdroják sám o sobě nepůjde přeložit, protože nemáme třídu, na níž závisí. Celý kód vystavím až po kontrole příslušných úloh."

Proc se ceka s vystavenim az na odevzdani uloh? Primo uloha na toto tema tam letos nebyla a myslim, ze by bylo lepsi vystavit vsechny materialy naraz. Jednak se to potom vystavit zapomene a jednak by studenti meli mit k dispozici kompletni priklady.

[13]

Do posledni odrazky bych doplnil

"Větvení if() {...} else {...} - složené závorky se používají k uzavření příkazů do sekvence - ve smyslu pascalského begin/end. (Pokud příslušná větev obsahuje pouze jeden příkaz, složené závorky se sice uvádět nemusí, ale je silně doporučeno je tam uvést vždy. Chybějící složené závorky bývají zdrojem nepříjemných chyb.)"

Ale jeste to zvaz, kdyz to po sobe ctu, nevim, jestli to radeji nenechat v puvodni podobe... No, mas to vysvetlene v prednsce c. 4, takze bych to nechal tak, jak to je.

[14]

Hned v prvnim radku chybi mezera pred uz.

"používá se spíše u proměnných než metod, ale dost často se vyskytuje z lenosti programátora, kterému se nechce psát protected" - nemelo tam byt spise private?

"Mohlo by mít význam, je-li práce rozdělena na více lidí na jednom balíku pracuje jen jeden člověk - pak si může přátelským přístupem chránit své neveřejné prvky/třídy -> nesmí ovšem nikdo jiný chtít mé třídy rozšiřovat a používat přitom přátelské prvky." - nemyslim, ze je tu souvislost s organizaci vyvojoveho tymu. Naopak jsem presvedcen, ze organizace do baliku a trid musi odpovidat vyhradne pozadavkum spravne dekompozice a nikoliv rozdeleni tymu. Proto bych tam toto radeji neuvadel. Vyznam pratelskych prvku spatruji v pripade, kdy nemaji byt soucasti verejneho rozhrani objektu a nemaji slouzit ani pro pouziti v podtridach, ale potrebuju k nim pristupovat z jinych trid daneho baliku. Napr. implementuji nejake read-only rozhrani, ja je potrebuji menit pouze z jine tridy a je to moc velke na to, aby to byla vnorena trida.

Mozna bychom o tom mohli prilezitostne hodit malou diskusi. Ja bych doporucil imlicitni prava nastavovat jako private, protoze to odpovida defenzivnimu pristupu (a nemusim se pak zabyvat ochranou integrity dane tridy z pohledu jejich potomku), ale vim, ze ty na to mas jiny nazor :-).

Čtvrtá přednáška

[15]

Na konec bych mozna doplnil poznamku v zavorce

"v Pascalu středník příkazy odděluje, v Javě (C/C++) ukončuje (tj. nesmí tam nikdy chybět)"

[16]

Do toho prikladu bych asi z pedagogickych doplnil upozorneni uzivateli, ze zadane cislo bylo spatne a ze ho ma zadat znovu.

Pátá přednáška

http://is.muni.cz/el/1433/podzim2004/PB162/um/prednaska5/minimodule109.html

Objektovym typem jsou i pole.

http://is.muni.cz/el/1433/podzim2004/PB162/um/prednaska5/minimodule115.html

Momentalne Java interne pouziva prave kodovani UTF-16, aby mohla do sekvence 16-bitovych hodnot ukladat vsechny znaky z Unicode. (http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Character.html#unicode)

Ale to samozrejme neni v rozporu s uvedenym textem, akorat bych tam mozna doplnil ten odkaz pro zvidave. A možná přidal poznámku o vkládání znaků pomocí escape sekvencí a utilitě native2ascii (pro případ, že potřebuji opravdu nějaký národní znak do textu vložit).

Šestá přednáška

http://is.muni.cz/el/1433/podzim2004/PB162/um/prednaska6/minimodule93.html

Možná by se dala doplnit poznámka, že vícenásobná dědičnost se v Javě dá nahradit delegováním.

Sedmá přednáška

http://is.muni.cz/el/1433/podzim2004/PB162/um/prednaska7/minimodule104.html

Doplnil bych odkaz na commons-logging (http://jakarta.apache.org/commons/logging/)

http://is.muni.cz/el/1433/podzim2004/PB162/um/prednaska7/assert.html

Myslim, ze uvedeny priklad neni moc vhodny - pripady tohoto typu by se mely resit vyjimkou IllegalArgumentException, protoze mi spatny argument konstruktoru muze kdokoliv predat v podstate kdykoliv. Ze jde v tomto pripade o neverejnou tridu je sice "polehcujici okolnost", ale obavam se, ze si toho studenti nevsimnou a budou pak podobne pripady resit podminku typu assert misto spravneho uziti vyjimky.

Podminky typu assert by se mely dle meho nazoru pouzivat k overeni splneni invariantu tridy nebo metody (jehoz zmenu muze zpusobit kod dane metody), ale nikdy ne k overeni korektnosti vstupnich parametru metody ci konstruktoru, jejimz puvodcem je kod nekde "venku".

Hodne pouzivame aserce treba v indexacnich metodach, kdy overujeme, ze je struktura konzistentni. Tam je dulezita moznost to vypnout, nebot to prinasi nezanedbatelnou rezii. Vhodnym prikladem by mohla byt treba nejaka radici metoda nebo neco podobneho.

http://is.muni.cz/el/1433/podzim2004/PB162/um/prednaska7/minimodule126.html

Ten pojem "líné vyhodnocování" je vseobecne pouzivany? Abych se priznal, tak ho vidim poprve v zivote a libi se mi vice termin "zkracene vyhodnocovani".

http://is.muni.cz/el/1433/podzim2004/PB162/um/prednaska7/foil25.html

Priklad porusuje kontrakt metody Object.equals(Object), nebot tato metoda by nikdy nemela vyhodit vyjimku, ale vratit bud true nebo false! (Narozdil od metody compareTo, ktera ale pro "neporovnatelne" objekty musi vyhodit ClassCastException, nikoliv IllegalArgumentException)

Dost casto se na tento priklad odvolavaji studenti, kterym za to strhavame body ve cvicenich z PB162 nebo PA165 :-(.

Asi by stalo za to tento problem trosicku komentovat - chovani metody equals odpovida relaci ekvivalence, ktera je v predikatove logice definovana nad celym univerzem dane realizace jazyka predikatove logiky. Timto univerzem je v pripade Javy trida Object, takze mohu zdanlive nelogicky porovnavat jablka s hruskami.

Zatimco compareTo implementuje relaci uplneho usporadani, ktere je mozne definovat pouze pro omezenou domenu hodnot.

http://is.muni.cz/el/1433/podzim2004/PB162/um/prednaska7/foil26.html

Vetu

"Jakmile u třídy překryjeme metodu equals, měli bychom současně překrýt objektů i metodu hashCode:"

bych nahradil vetou

"Jakmile u třídy překryjeme metodu equals, musíme současně překrýt i metodu hashCode:"

http://is.muni.cz/el/1433/podzim2004/PB162/um/prednaska7/foil27.html

Chyba v metode equals - viz komentar ke slajdu c. 25.

Zaroven bych doplnit velmi vyrazne upozorneni, ze v metode equals bychom nikdy nemeli porovnavat pomoci hodnot vracenych metodou hashCode()!

Formulace „přehráváme“ není dle mého názoru optimální; navíc by se v češtině měly uvozovky používat výhradně pro přímou řeč.

http://is.muni.cz/el/1433/podzim2004/PB162/um/prednaska7/minimodule131.html

Možná bych doplnil poznámku, že konstrukce s operátorem zřetězění překládá překladač jako operace s třídou StringBuffer (nebo možná u verze 5.0 s třídou StringBuilder)

http://is.muni.cz/el/1433/podzim2004/PB162/um/prednaska7/minimodule132.html

Je to docela stručné a obsah neodpovídá nadpisu (vypadá to, že se ten slajd zapomněl dodělat).

Osmá přednáška

[17]

metoda Comparable.compareTo(Object) ma pro nekompatibilni objekty vyhodit ClassCastException, ne IllegalArgumentException

http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Comparable.html#compareTo(T)

Takze staci pouzit

public int compareTo(Object o) {

   Clovek c = (Clovek) o;
   return prijimeni.compareTo(c.prijimeni);

}

Devátá přednáška

http://is.muni.cz/el/1433/podzim2004/PB162/um/prednaska9/generics.html

místo 'budeme „riskovat“ runtime výjimku' bych použil 'budeme riskovat běhovou výjimku' (když už studenty pérujeme, aby psali své práce hezky česky)

http://is.muni.cz/el/1433/podzim2004/PB162/um/prednaska9/generics_wildcards.html

Místo správného pojmu seřadit je v textu použito nesprávné slovo setřídit.

Desátá přednáška

http://is.muni.cz/el/1433/podzim2004/PB162/um/prednaska10/minimodule188.html

Odstranil bych uvozovky u slov odstranit a pokrývat.

Dále moc nesouhlasím s tvrzením "není dobré výjimkami pokrývat chyby programu samotného - to je hrubé zneužití". Pokud chci mít robusní kód, musím používat defenzívní přístup a být připraven i na chyby programu a programátora. Musím se pouze rozhodnout, kdy použít výjimku (kontrola parametrů apod.) a kdy dám přednost konstrukci assert (kontrola invariantů).

Je nutné samozřejmě striktně rozdělovat výjimky programátorem neovlivnitelné a vzniklé chováním okolí (řešeno pomocí hlídaných výjimek) a výjimky vzniklé chybou programátora (nehlídané výjimky).