Wat voor verschil dat finalmaakt tussen de onderstaande code. Heeft het enig voordeel om de argumenten als finalte verklaren.

public String changeTimezone( Timestamp stamp, Timezone fTz, Timezone toTz){  
    return ....
}
public String changeTimezone(final Timestamp stamp, final Timezone fTz, 
        final Timezone toTz){
    return ....
}

Antwoord 1, autoriteit 100%

Omdat een formele methodeparameter een lokale variabele is, kun je ze alleen benaderen vanuit innerlijke anonieme klassen als ze als definitief zijn gedeclareerd.

Dit bespaart u het declareren van een andere lokale laatste variabele in de hoofdtekst van de methode:

void m(final int param) {
        new Thread(new Runnable() {
            public void run() {
                System.err.println(param);
            }
        }).start();
    }

Antwoord 2, autoriteit 29%

Extract uit Het laatste woord over het laatste zoekwoord

Definitieve parameters

Het volgende voorbeeld geeft de definitieve parameters aan:

public void doSomething(final int i, final int j)
{
  // cannot change the value of i or j here...
  // any change would be visible only inside the method...
}

finale wordt hier gebruikt om ervoor te zorgen dat de twee
indexen i en j zullen niet per ongeluk zijn
resetten volgens de methode. Het is een handige manier
om te beschermen tegen een verraderlijke bug
dat ten onrechte de waarde van verandert
uw parameters. In het algemeen,
korte methoden zijn een betere manier om
beschermen tegen deze klasse van fouten, maar
laatste parameters kunnen handig zijn
aanvulling op uw codeerstijl.

Merk op dat de uiteindelijke parameters dat niet zijn
beschouwd als onderdeel van de methode
handtekening, en worden genegeerd door de
compiler bij het oplossen van methodeaanroepen.
Parameters kunnen definitief worden verklaard (of
niet) zonder invloed op hoe de
methode wordt overschreven.

Antwoord 3, autoriteit 23%

De finale voorkomt dat u een nieuwe waarde aan de variabele toewijst, en dit kan handig zijn bij het opsporen van typefouten. Stilistisch gezien wil je misschien de ontvangen parameters ongewijzigd laten en alleen toewijzen aan lokale variabelen, dus final zou helpen om die stijl af te dwingen.

Ik moet toegeven dat ik me zelden herinner om final te gebruiken voor parameters, misschien zou ik dat moeten doen.

public int example(final int basicRate){
    int discountRate;
    discountRate = basicRate - 10;
    // ... lots of code here 
    if ( isGoldCustomer ) {
        basicRate--;  // typo, we intended to say discountRate--, final catches this
    }
    // ... more code here
    return discountRate;
}

Antwoord 4, autoriteit 10%

Het maakt niet veel uit. Het betekent alleen dat je niet kunt schrijven:

stamp = null;
fTz = new ...;

maar je kunt nog steeds schrijven:

stamp.setXXX(...);
fTz.setXXX(...);

Het is vooral een hint voor de onderhoudsprogrammeur die je volgt dat je geen nieuwe waarde gaat toekennen aan de parameter ergens in het midden van je methode waar het niet voor de hand ligt en daarom voor verwarring kan zorgen.

>

Antwoord 5, autoriteit 3%

Het laatste sleutelwoord, wanneer gebruikt voor parameters/variabelen in Java, markeert de verwijzing als definitief. In het geval dat een object wordt doorgegeven aan een andere methode, maakt het systeem een ​​kopie van de referentievariabele en geeft deze door aan de methode. Door de nieuwe referenties definitief te markeren, bescherm je ze tegen herplaatsing. Het wordt soms als een goede codeerpraktijk beschouwd.

Antwoord 6, autoriteit 3%

Voor de hoofdtekst van deze methode zal het sleutelwoord finalvoorkomen dat de argumentverwijzingen per ongeluk opnieuw worden toegewezen, wat een compileerfout geeft in die gevallen (de meeste IDE’s zullen meteen klagen). Sommigen zullen misschien beweren dat het gebruik van finalin het algemeen waar mogelijk de zaken zal versnellen, maar dat is niet het geval in recente JVM’s.

Antwoord 7, autoriteit 2%

Twee voordelen die ik zie worden opgesomd:

1 Als u het methodeargument als definitief markeert, wordt hertoewijzing van het argument binnen de methode voorkomen

Van jou voorbeeld

   public String changeTimezone(final Timestamp stamp, final Timezone fTz, 
            final Timezone toTz){
    // THIS WILL CAUSE COMPILATION ERROR as fTz is marked as final argument
      fTz = Calendar.getInstance().getTimeZone();     
      return ..
    }

In een gecompliceerde methode zal het markeren van de argumenten als definitief helpen bij de onbedoelde interpretatie van deze argumenten als lokale variabelen van de methode en opnieuw toewijzen als compiler zal deze gevallen markeren zoals getoond in het voorbeeld.

2 Het argument doorgeven aan een anonieme innerlijke klas

Omdat een formele methodeparameter een lokale variabele is, heb je er alleen toegang toe vanuit innerlijke anonieme klassen als ze als definitief zijn gedeclareerd.

Antwoord 8

Het is gewoon een constructie in Java om je te helpen een contract te definiëren en je eraan te houden. Een soortgelijke discussie hier: http://c2.com/cgi/wiki?JavaFinalConsideredEvil

BTW – (zoals de twiki zegt), het markeren van args als definitief is over het algemeen overbodig als je goede programmeerprincipes volgt en de inkomende argumentreferentie vervolgens opnieuw toewijst / opnieuw definieert.

In het ergste geval, als u de args-referentie opnieuw definieert, heeft dit geen invloed op de werkelijke waarde die aan de functie wordt doorgegeven – aangezien alleen een referentie is doorgegeven.

Antwoord 9

Ik heb het over het markeren van variabelen en velden in het algemeen – is niet alleen van toepassing op methodeargumenten. (Het markeren van methoden/klassen als definitief is iets heel anders).

Het is een gunst voor de lezers/toekomstige beheerders van uw code. Samen met een verstandige naam van de variabele, is het nuttig en geruststellend voor de lezer van uw code om te zien/begrijpen wat de variabelen in kwestie vertegenwoordigen – en het is geruststellend voor de lezer dat wanneer u de variabele in hetzelfde bereik ziet, de betekenis blijft hetzelfde, zodat hij niet op zijn hoofd hoeft te krabben om er altijd achter te komen wat een variabele in elke context betekent. We hebben te veel misbruik van het “hergebruiken” van variabelen gezien, waardoor zelfs een kort codefragment moeilijk te begrijpen is.

Antwoord 10

– In het verleden (vóór Java 8 🙂 )

Expliciet gebruik van “final” trefwoord beïnvloedde de toegankelijkheid van de methodevariabele voor interne anonieme klassen.

– In moderne taal (Java 8+) is dergelijk gebruik niet nodig:

Java heeft “effectief definitieve” variabelen geïntroduceerd. Lokale variabelen en methodeparameters worden als definitief beschouwd als de code geen verandering van de waarde van de variabele impliceert. Dus als u een dergelijk trefwoord in Java8+ ziet, kunt u ervan uitgaan dat het niet nodig is. De introductie van “effectief definitief” zorgt ervoor dat we minder code hoeven te typen bij het gebruik van lambda’s.

Antwoord 11

Het laatste sleutelwoord voorkomt dat u een nieuwe waarde aan de parameter toewijst. Ik wil dit graag uitleggen met een eenvoudig voorbeeld

Stel dat we een methode hebben

methode1(){

Datum dateOfBirth =new Date(“1/1/2009”);

methode2(dateOfBirth);

methode3(dateOfBirth); }

public mehod2(Date dateOfBirth) {
….
….
….
}

public mehod2(Date dateOfBirth) {
….
….
….
}

In het bovenstaande geval, als de “dateOfBirth” een nieuwe waarde krijgt in methode2 dan zou dit resulteren in de verkeerde uitvoer van methode3. Omdat de waarde die wordt doorgegeven aan methode3 niet is wat hij was voordat hij werd doorgegeven aan methode2. Dus om te voorkomen dat dit laatste zoekwoord wordt gebruikt voor parameters.

En dit is ook een van de beste methoden voor Java-codering.