Why should I use the keyword “final” on a method p

问题:

I can\'t understand where the final keyword is really handy when it is used on method parameters.

If we exclude the usage of anonymous classes, readability and intent declaration then it seems almost worthless to me.

Enforcing that some data remains constant is not as strong as it seems.

• If the parameter is a primitive then it will have no effect since the parameter is passed to the method as a value and changing it will have no effect outside the scope.

• If we are passing a parameter by reference, then the reference itself is a local variable and if the reference is changed from within the method, that would not have any effect from outside of the method scope.

Consider the simple test example below. This test passes although the method changed the value of the reference given to it, it has no effect.

public void testNullify() {
    Collection<Integer> c  = new ArrayList<Integer>();      
    nullify(c);
    assertNotNull(c);       
    final Collection<Integer> c1 = c;
    assertTrue(c1.equals(c));
    change(c);
    assertTrue(c1.equals(c));
}

private void change(Collection<Integer> c) {
    c = new ArrayList<Integer>();
}

public void nullify(Collection<?> t) {
    t = null;
}

回答1:

Sometimes its nice to be explicit(for readability) that the variable doesn\'t change. Here\'s a simple example where using final can save some possible headaches

public void setTest(String test) {
    test = test;
}

if you forget the \'this\' keyword on a setter the variable you want to set doesn\'t get set. However if you used the final keyword on the parameter then the bug would be caught at compile time.

回答2:

Stop a Variable’s Reassignment

While these answers are intellectually interesting, I\'ve not read the short simple answer:

Use the keyword final when you want the compiler to prevent a variable from being re-assigned to a different object.

Whether the variable is a static variable, member variable, local variable, or argument/parameter variable, the effect is entirely the same.

Example

Let’s see the effect in action.

Consider this simple method, where the two variables (arg and x) can both be re-assigned different objects.

// Example use of this method: 
//   this.doSomething( \"tiger\" );
void doSomething( String arg ) {
  String x = arg;   // Both variables now point to the same String object.
  x = \"elephant\";   // This variable now points to a different String object.
  arg = \"giraffe\";  // Ditto. Now neither variable points to the original passed String.
}

Mark the local variable as final. This results in a compiler error.

void doSomething( String arg ) {
  final String x = arg;  // Mark variable as \'final\'.
  x = \"elephant\";  // Compiler error: The final local variable x cannot be assigned. 
  arg = \"giraffe\";  
}

Instead, let’s mark the parameter variable as final. This too results in a compiler error.

void doSomething( final String arg ) {  // Mark argument as \'final\'.
  String x = arg;   
  x = \"elephant\"; 
  arg = \"giraffe\";  // Compiler error: The passed argument variable arg cannot be re-assigned to another object.
}

Moral of the story:

If you want to ensure a variable always points to the same object, mark the variable final.

Never Reassign Arguments

As good programming practice (in any language), you should never re-assign a parameter/argument variable to an object other than the object passed by the calling method. In the examples above, one should never write the line arg =. Since humans make mistakes, and programmers are human, let’s ask the compiler to assist us. Mark every parameter/argument variable as \'final\' so that the compiler may find and flag any such re-assignments.

In Retrospect

As noted in other answers… Given Java\'s original design goal of helping programmers to avoid dumb mistakes such as reading past the end of an array, Java should have been designed to automatically enforce all parameter/argument variables as \'final\'. In other words, Arguments should not be variables. But hindsight is 20/20 vision, and the Java designers had their hands full at the time.

Another case added for the completeness

public class MyClass {
    private int x;
    //getters and setters
}

void doSomething( final MyClass arg ) {  // Mark argument as \'final\'.

   arg =  new MyClass();  // Compiler error: The passed argument variable arg  cannot be re-assigned to another object.

   arg.setX(20); // allowed
  // We can re-assign properties of argument which is marked as final
 }

回答3:

Yes, excluding anonymous classes, readability and intent declaration it\'s almost worthless. Are those three things worthless though?

Personally I tend not to use final for local variables and parameters unless I\'m using the variable in an anonymous inner class, but I can certainly see the point of those who want to make it clear that the parameter value itself won\'t change (even if the object it refers to changes its contents). For those who find that adds to readability, I think it\'s an entirely reasonable thing to do.

Your point would be more important if anyone were actually claiming that it did keep data constant in a way that it doesn\'t - but I can\'t remember seeing any such claims. Are you suggesting there\'s a significant body of developers suggesting that final has more effect than it really does?

EDIT: I should really have summed all of this up with a Monty Python reference; the question seems somewhat similar to asking \"What have the Romans ever done for us?\"

回答4:

Let me explain a bit about the one case where you have to use final, which Jon already mentioned:

If you create an anonymous inner class in your method and use a local variable (such as a method parameter) inside that class, then the compiler forces you to make the parameter final:

public Iterator<Integer> createIntegerIterator(final int from, final int to)
{
    return new Iterator<Integer>(){
        int index = from;
        public Integer next()
        {
            return index++;
        }
        public boolean hasNext()
        {
            return index <= to;
        }
        // remove method omitted
    };
}

Here the from and to parameters need to be final so they can be used inside the anonymous class.

The reason for that requirement is this: Local variables live on the stack, therefore they exist only while the method is executed. However, the anonymous class instance is returned from the method, so it may live for much longer. You can\'t preserve the stack, because it is needed for subsequent method calls.

So what Java does instead is to put copies of those local variables as hidden instance variables into the anonymous class (you can see them if you examine the byte code). But if they were not final, one might expect the anonymous class and the method seeing changes the other one makes to the variable. In order to maintain the illusion that there is only one variable rather than two copies, it has to be final.

回答5:

I use final all the time on parameters.

Does it add that much? Not really.

Would I turn it off? No.

The reason: I found 3 bugs where people had written sloppy code and failed to set a member variable in accessors. All bugs proved difficult to find.

I\'d like to see this made the default in a future version of Java. The pass by value/reference thing trips up an awful lot of junior programmers.

One more thing.. my methods tend to have a low number of parameters so the extra text on a method declaration isn\'t an issue.

回答6:

Using final in a method parameter has nothing to do with what happens to the argument on the caller side. It is only meant to mark it as not changing inside that method. As I try to adopt a more functional programming style, I kind of see the value in that.

回答7:

Personally I don\'t use final on method parameters, because it adds too much clutter to parameter lists. I prefer to enforce that method parameters are not changed through something like Checkstyle.

For local variables I use final whenever possible, I even let Eclipse do that automatically in my setup for personal projects.

I would certainly like something stronger like C/C++ const.

回答8:

Since Java passes copies of arguments I feel the relevance of it is rather limited. I guess this comes from the C++ era where you could prohibit the reference content of being changed by doing a const char const *. I feel this kind of stuff makes you believe the developer is inherent stupid as f*** and needs to be protected against truly every character he types. In all humbleness must I say I write very few bugs, even though I onmit the final unless whan I don\'t want someone to override my methods and stuff... Maybe I\'m just an old-school dev... :-O

回答9:

Short answer: final helps a tiny bit but... use defensive programming on the client side instead.

Indeed, the problem with final is that it only enforces the reference is unchanged, gleefully allowing the referenced object members to be mutated, unbeknownst to the caller. Hence the best practice in this regard is defensive programming on the caller side, creating deeply immutable instances or deep copies of objects that are in danger of being mugged by unscrupulous APIs.

回答10:

One additional reason to add final to parameter declarations is that it helps to identify variables that need to be renamed as part of a \"Extract Method\" refactoring. I have found that adding final to each parameter prior to starting a large method refactoring quickly tells me if there are any issues I need to address before continuing.

However, I generally remove them as superfluous at the end of the refactoring.

回答11:

I never use final in a parameter list, it just adds clutter like previous respondents have said. Also in Eclipse you can set parameter assignment to generate an error so using final in a parameter list seems pretty redundant to me. Interestingly when I enabled the Eclipse setting for parameter assignment generating an error on it caught this code (this is just how I remember the flow, not the actual code. ) :-

private String getString(String A, int i, String B, String C)
{
    if (i > 0)
        A += B;

    if (i > 100)
        A += C;

    return A;
}

Playing devil\'s advocate, what exactly is wrong with doing this?

回答12:

Follow up by what Michel\'s post. I my own made myself another example to explain it. I hope it could help.

public static void main(String[] args){
    MyParam myParam = thisIsWhy(new MyObj());
    myParam.setArgNewName();

    System.out.println(myParam.showObjName());
}

public static MyParam thisIsWhy(final MyObj obj){
    MyParam myParam = new MyParam() {
        @Override
        public void setArgNewName() {
            obj.name = \"afterSet\";
        }

        @Override
        public String showObjName(){
            return obj.name;
        }
    };

    return myParam;
}

public static class MyObj{
    String name = \"beforeSet\";
    public MyObj() {
    }
}

public abstract static class MyParam{
    public abstract void setArgNewName();
    public abstract String showObjName();
}

From the code above, in the method thisIsWhy(), we actually didn\'t assign the [argument MyObj obj] to a real reference in MyParam. In instead, we just use the [argument MyObj obj] in the method inside MyParam.

But after we finish the method thisIsWhy(), should the argument(object) MyObj still exist?

Seems like it should, because we can see in main we still call the method showObjName() and it need to reach obj. MyParam will still uses/reaches the method argument even the method was already return!

How Java really achieve this is to generate a copy also is a hidden reference of the argument MyObj obj inside the MyParam object ( but it\'s not a formal field in MyParam so that we can\'t see it )

As we call \"showObjName\", it will use that reference to get the corresponding value.

But if we didn\'t put the argument final, which leads a situation we can reassign a new memory(object) to the argument MyObj obj.

Technically there\'s no clash at all! If we are allowed to do that, below will be the situation:

1. We now have a hidden [MyObj obj] point to a [Memory A in heap] now live in MyParam object.
2. We also have another [MyObj obj] which is the argument point to a [Memory B in heap] now live in thisIsWhy method.

No clash, but \"CONFUSING!!\" Because they are all using the same \"reference name\" which is \"obj\".

To avoid this, set it as \"final\" to avoid programmer do the \"mistake-prone\" code.