Privandrovalci z C jsem myslel Vase kolegy, ne Vas osobne. A ze je instanceof nekdy uzitecne, o tom nemam pochyb. Sam jej obcas pouzivam.
K puvodni otazce, tj. rychlosti instanceof a volani metody pres interface: V prezentaci na http://wiki.jvmlangsummit.com/images/c/c9/Ohrstrom-lambdas-2010-07-26.pdf Fredrik Öhrström na slidu 9 rika: How fast is invokeinterface? Depends on the implementation: - JRockit uses a constant time lookup - Hotspot uses an iteration over the implemented interfaces Je tam i neco malo o instanceof. Z.T. -- Zdenek Tronicek FIT CTU in Prague Navrhujete API? http://www.java.cz/article/evoluceapi neme...@gmail.com napsal(a): > Se nam to trochu zvrhlo. Z puvodny otazky proc je neco rychlejsi nez neco > jineho, tu mam otazku typu, "proc to chces vlastne vedet" > > Takze pro uprseneni proc se na to ptam. Nejsem puvodni Ceckar, ba naopak. > S > Ceckari ale hodne pracuji a ty prave prichazy (jak vam neuniklo) s > konstrukcemi typu if(getID()==...) nebo instanceof. Na tyhle cckove > archetypy, ktere zkouseji tahat do javy, jsem mel dva argumenty. Prvni je > ze > to neni objektove (coz na cckare moc neplati, protoze nemysli v objektech) > a > druhy (ktery akceptuji mnohem radeji), ze to jvm vykona mnohem rychleji. > > Jednou jsem si chtel ten druhy argument overit a vysledkem byl muj > prispevek > do konference tak tedy, proto jsem se na tohle ptal. > > "Zdeněk Troníček" writes: > >> Dobry den, >> >> tohle je typicke pro privandrovalce z jazyka C (nic ve zlem, C je super >> jazyk). Tito programatori chteji u kazdeho prikazu vedet, jak se prelozi >> a >> jak se provadi (to samo o sobe samozrejme neni spatne, spis naopak) a >> pak >> se snazi pouzivat ty "nejefektivnejsi" konstrukce. >> Jakkoliv se to muze zdat prinosne ci alespon neskodne, vetsinou to vede >> k >> tomu, ze kod je zaplevelen temito "efektivnimi" konstrukcemi, ktere >> obvykle snizuji citelnost a jen malokdy vedou k tomu, ze program je >> skutecne rychlejsi. Proto by mel kazdy rozumny vedouci projektu takoveho >> "optimalizatora" vytahat za usi. >> Pokud chcete optimalizovat, pustte profiler na funkcni program, najdete >> misto, kde program travi vetsinu casu ("measure, don't guess") a pak >> optimalizujte. Snazit se odhadnout, kde bude potreba optimalizace, je >> hadani a i ti, kteri rozumeli mailu Ladi Thona v tomto vlaknu, by meli >> uspesnost takoveho hadani pravdepodobne nizkou. Navic, dokud neni >> potreba >> optimalizovat, nema smysl nejakou optimalizaci delat. >> >> Takze: 1) zamerte se na spravny navrh (jak tu psal Dagi), >> 2) piste srozumitelny kod, >> 3) pokud je vysledny program pomaly, pouzijte profiler a pak pripadne >> optimalizujte. Ne vsak drive! >> >> Jinak potreba instanceof by vas mela vest k zamysleni, zda je vas navrh >> optimalni a zda by misto instanceof nebylo lepsi pouzit virtualni >> metodu. > > Razim uplne stejny pristup. Dokonce pokazde kdyz vidim if tak se ptam proc > to neni mozne udelat pomoci interface a volanim metody. Skutecne jsou ale > problemy, ktere se pomoci objektu a dedeni resi velmi obtizne. V nasem > pripade je to c-ckovy kod na nejnizsi vrstve, ktery komunikuje s FSM v > jave. > Takze vasi dobre minenou radu musim brat s rezervou. > > P.N. > >> >> Z.T. >> -- >> Zdenek Tronicek >> FIT CTU in Prague >> >> >
