[Javalist] to final or not to final

[istvan.ketler at lhsystems.com]

Csakhogy ehhez az is kell, hogy a példányváltozó és a paraméter típusa azonos legyen, így máris egy valamekkora részét kiszűrtem a problémának. Egyébként sem ad (nekem) semmilyen biztonságérzetet, mert nem azért használom hogy ne tudjam módosítani a változót.

A lenti harmadik pontnál meg ha véletlen lenne az a módosítás, akkor valahol megelőzné egy értékadás (hiszen nagyrészt azért használja hibásan a későbbi módosító valahol a törzsben, mert nem tudja hogy van már ilyen paraméter).


______________________________
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

-----Original Message-----

From: javalist-bounces at lists.javaforum.hu [mailto:javalist-bounces at lists.javaforum.hu] On Behalf Of Tamás Viktor
Sent: Thursday, January 31, 2013 11:53 AM
To: Java lista
Subject: Re: [Javalist] to final or not to final

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
>
_______________________________________________
Javalist mailing list
Javalist at lists.javaforum.hu
http://lists.javaforum.hu/mailman/listinfo/javalist