[Javalist] to final or not to final

[Tamás Viktor]

A példádban a 'final' csak attól véd meg, hogy a referenciánknak új
értéket adj, de attól nem véd meg, hogy beletúrj a paraméterként
átadott objektumok állapotába (ha azok nem immutable-ok). Kvázi hamis
biztonságérzetet ad.

Nem szeretem a final-t használni metódusparaméterekre, fieldekre viszont igen.
V

2013/1/31  <istvan.ketler at lhsystems.com>:
> Felmerült a memóriataposó blogban hogy miért is kell nekünk a final...
>
>
>
> 1.       Némelyek állítják, hogy növeli az olvashatóságot. Szerintem rontja,
> mert hosszabb lesz a paraméterlista.
>
> 2.       Némelyek állítják, hogy világosabb a „szándék”. Hát ez egy nagyon
> érdekes vélemény... Amikor kap a metódusom egy paramétert, akkor a szándékom
> az hogy ezt a paramétert használjam a metódus céljaira. Ha a metódus
> „céljai” között szerepel az hogy a feldolgozás során a pillanatnyi érték
> változzék, akkor mi is a szándék? Nem is beszélve a „default” vagy
> „optional” paraméter értékekről (lásd később), amelyek azért lehetnek
> hasznosak.
>
> 3.       Azt kevesebben mondják, hogy megvéd a paraméter véletlen
> módosításától. Márpedig ez egy valóban hasznos hatása. Ha valahol egy
> hasonló nevű lokális változót kezd el használni az ember, egy esetleges
> későbbi módosító könnyebben, de még az eredeti szerző is „benézheti” a
> változó nevét, különösen ha siet, és csak gyorsan kiválasztja az Eclipse
> által felajánlott nevek közül.
>
> 4.       Azt is inkább kevesen mondják, megvéd attól is, hogy az
> objektumváltozó helyett a paramétert módosítsuk ha a paraméter neve
> történetesen megegyezik a példányváltozóéval. Márpedig ez előfordul, és a
> this-t kevesen teszik ki a példányváltozó elé (pedig egyike az Eclipse
> igazán hasznos kódformázásainak, és ez **tényleg** növeli a láthatóságot,
> hiszen minden előfordulásnál hangsúlyozza, hogy a példányváltozóról van
> szó).
>
>
>
> Szóval igen, szerintem „to final”, de nem holmi szándék és egyebek miatt (az
> IMHO bullshit), hanem azért mert megvéd a sajnálatos (és egyébként nehezen
> észrevehető) hibáktól.
>
>
>
> A final akkor lenne igazán hasznos, ha kombinálható lenne egy „default”
> paraméterértékkel is. Pl ilyenkor egy kicsit idegesítő, ha **kötelező**a
> használata, méghozzá kivétel nélkül:
>
>
>
> public NumericResult compute(
>
>         final NumericValue param1,
>
>         final NumericValue param2,
>
>         ComputationProvider provider
>
> ) {
>
>     if (provider == null) {
>
>         provider = new MyDefaultComputationProvider();
>
>     }
>
>     // ...
>
> }
>
>
>
> Mert ehelyett most így kell írni:
>
>
>
> public NumericResult compute(
>
>         final NumericValue param1,
>
>         final NumericValue param2,
>
>         final ComputationProvider providerParam
>
> ) {
>
>     ComputationProvider provider = providerParam;
>
>     if (provider == null) {
>
>         ComputationProvider provider = new MyDefaultComputationProvider();
>
>     }
>
>     // ...
>
> }
>
>
>
> Nem mondom hogy nagyon más, cserében pont azt a védelmet veszítjük el, amit
> egyébként nyújtana. Annyi annotáció van, nem tud valaki egy @onNull <param>
> <value> formát is? :)
>
>
>
> De ha már itt vagyunk, legyen itt egy „szép” megoldás is:
>
>
>
> public NumericResult compute(
>
>         final NumericValue param1,
>
>         final NumericValue param2,
>
>         final ComputationProvider provider
>
> ) {
>
>     if (provider == null) {
>
>         return compute(param1, param2);
>
>     }
>
>     // ...
>
> }
>
>
>
> public NumericResult compute(final NumericValue param1, final NumericValue
> param2) {
>
>     return compute(param1, param2, new MyDefaultComputationProvider());
>
> }
>
>
>
> Ugye a háromparaméteres esetén is lehet hogy null az értéke (mert a hívó nem
> akarja ellenőrizni), ezért ilyenkor „átkonvertáljuk” kétparaméteressé,
> amelyik újrahívja a háromparaméterest csak most nem null provider-rel. Így
> aztán final is van, meg védelem is.
>
>
>
> Üdv,
>
>
>
> Iván
>
> ______________________________
>
> István Ketler
>
> Senior Consultant
>
>
>
> Lufthansa Systems Hungária Kft.
>
> Development Center Pest
>
> Neumann János u. 1/e
>
> 1117 Budapest
>
> Hungary
>
> Phone: +36 1 887-2815
>
> Fax: +36 1 887-0577
>
> Mobile: +36 30 600-4936
>
> E-mail: istvan.ketler at LHsystems.com
>
> www.LHsystems.com
>
>
>
>
>
> Sitz der Gesellschaft / Corporate Headquarters: Lufthansa Systems Hungaria
> Kft, Budapest, Fovarosi Birosag 01-09-463417
> Geschaeftsfuehrung / Management Board: Peter Sipos
>
>
>
> _______________________________________________
> Javalist mailing list
> Javalist at lists.javaforum.hu
> http://lists.javaforum.hu/mailman/listinfo/javalist
>