[Java lista] final formalis parameter

[biziclop]

A fnal parameternek nem az a legfontosabb tulajdonsaga, hogy
modosithatatlan. Normalis esetben az ember amugy sem irja felul a
bemeno parametereket. (Mondjuk ugy, hogy soha.)

A final parameter egyetlen igazi haszna, hogy egy local inner class
masolatot keszithet rola, vagyis hasznalhatja.

lsp

On 12/15/06, Laszlo.Marai at nokia.com <Laszlo.Marai at nokia.com> wrote:
>   Hali!
>
> >Egyrészt optimálisabb lesz (C esetén ilyenkor ha tudja, akkor
> >proci-regiszterbe teszi ehlyből, nem stack/heap whatever ,
> >hogy java-nál hogy van azzal kapcsolatban majd tapasztaltabban
> >kisegítenek minket :))
>
> Nem lesz optimalisabb. Valoszinuleg (en nem latom, hogy mitol
> lenne az). De biztos, hogy altalanossagban nem lehet ilyen
> kijelenteseket tenni, mert ahany VM, annyi fele optimalizalas.
>
> Meg aztan tok jelentektelen is, hogy hany ns ideig tart elerni
> egy int parametert egy metodusban. Feltehetoleg csinal
> valami ertelmes dolgot is, es akkor egeszen biztosan
> elhanyagolhato lesz a parameter kiolvasasanak az ideje.
>
> >Thinking in Java idevonatkozó része: (jó, static-ról beszél,
> >na) :L) "static final variables can be optimized by the JVM to
> >improve program speed. Program constants should thus be
> >declared as static and final. "
>
> Hat az a nem mindegy, hogy static az a final, vagy nem.
> A static final, _ha primitiv tipusrol beszelunk_ es
> forditasi idoben kiszamolhato az erteke, akkor gyakorlatilag
> egy konstans kifejezes, amit a fordito az eleres helyere szepen
> be tud helyettesiteni. Ha nem primitiv a tipus, vagy nem
> derul ki az erteke forditasi idoben pl.:
> static final int SOMETHING = calculateSomething() ),
> akkor ez az allitas mar nem lesz igaz, hiszen csak
> furas kozben, az osztaly betoltodesekor kap erteket a valtozo.
> (Viszont itt a JIT meg megteheti, hogy amikor elso alkalommal
> eri el egy kodreszlet a kerdeses valtozot, akkor allandora
> behelyettesiti a static final erteket a hivas helyen.)
>
> >Sokkal fontosabb hogy ha nem fog változni a metóduson belül
> >akkor azért (si) érdemes finalt-t elétenni (és itt jön be a
>
> Igy van. Sot, altalaban nem kivanatos, hogy a metodus parametere
> valtozzon, mert megteveszto, es konnyu elnezni, ezert akar
> mindenhova is ki lehetne irni a final-t. (Sot, olvastam olyan
> velemenyt is, hogy eleve hibat kene jeleznie a forditonak,
> ha megprobalod modositani a metodus parameter erteket.)
>
> Ez foleg konstrukltorokban illetve set metodusokban lehet
> erdekes, ahol viszonylag gyankran szerepel a
> this.something = something; formaju ertekadas, es ha
> elfeledkezik a this-rol az ember, akkor csak nez, hogy miert
> nem inicializalodott az objektum something nevu mezoje.
>
> Ha tudjuk, hogy az objektum eletciklusa folyaman nem fog
> valtozni a valtozo erteke, akkor azt is erdemes final-re
> venni:
>
> Pl.
>
> public class Clazz {
>     private final int something;
>
>     public Clazz( final something ) {
>         // Mivel mindket something final, ezert barmilyen ettol
>         // eltero ertekadasert hibat jelez a fordito.
>         this.something = something;
>
>         // Hibas (gyakori eliras):
>         something = something;
>
>        // Az is hiba, ha elfelejtesz erteket adni a this.something -nak!
>     }
> }
>
> >(de a kék+zöld könyv is jó, csak abból ilyeneket nem fogsz
> >kiolvasni...) Persze mindig az a kérdés hogy mi a cél.
>
> Az nem programozni tanit, csak egyszeruen a java nyelvet plusz
> a classlib egy reszet :).
>
> Ami meg lenyeges (az eredeti kerdezonek): mar a kerdesfelvetes is
> hibas gondolkodast sugall. Ha az is lenne a valasz, hogy gyorsit
> a final kiirasa, akkor sem lenne szabad csak emiatt hasznalni.
> Legalabbis addig nem, amig el nem keszult a kerdeses programreszlet, es
> ki nem merted, hogy valoban ez okozza a problemat. A legfontosabb az,
> hogy a programod azt irja le pontosan (es jol erthetoen), ami a feladat,
> es optimalizalni csak akkor szabad, ha van mit. Azt meg csak akkor
> tudod, ha kimerted (erre a profiler nevu eszkozt hasznaljuk). A
> java-val a VM es JIT miatt amugy is eleg nagy meglepetesek erhetik
> az embert, eleg nehez a kod irogatasa kozben elore meghasalni, hogy
> hol is kell majd (es foleg hogy) optimalizalni. (Ez mas nyelvekre is
> igaz, csak itt a JIT meg a VM pluszban is bekavar.)
>
>   Ba'ly,
>     Atleta
> _______________________________________________
> Javalist mailing list
> Javalist at javagrund.hu
> http://javagrund.hu/mailman/listinfo/javalist
>