[Javalist] to final or not to final

[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<mailto:istvan.ketler at LHsystems.com>
www.LHsystems.com<http://www.lhsystems.com/>


 
Sitz der Gesellschaft / Corporate Headquarters: Lufthansa Systems Hungaria Kft, Budapest, Fovarosi Birosag 01-09-463417
Geschaeftsfuehrung / Management Board: Peter Sipos


--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: <http://lists.javaforum.hu/pipermail/javalist/attachments/20130131/66074792/attachment.html>