Я никогда не использую final в списке параметров, он просто добавляет беспорядок, как говорили предыдущие респонденты. Также в Eclipse вы можете установить назначение параметров для генерации ошибки, поэтому использование final в списке параметров кажется мне излишним. Интересно, когда я включил параметр Eclipse для назначения параметров, генерируя ошибку, он поймал этот код (это как раз то, как я помню поток, а не фактический код.): -

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

    if (i > 100)
        A += C;

    return A;
}

Играя адвоката дьявола, что именно не так с этим?

Следуйте за сообщением Мишеля. Я сам сделал себе еще один пример, чтобы объяснить это. Я надеюсь, что это могло бы помочь.

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();
}

Из приведенного выше кода в методе thisIsWhy () мы фактически не присвоили [аргумент MyObj obj] реальную ссылку в MyParam. Вместо этого мы просто используем [аргумент MyObj obj] в методе внутри MyParam.

Но после завершения метода thisIsWhy (), должен существовать аргумент (объект) MyObj?

Похоже, должно быть, потому что мы можем видеть в основном, мы все еще вызываем метод showObjName (), и ему нужно достичь obj. MyParam все еще использует / достигает аргумента метода, даже если метод уже возвращался!

Как Java действительно достигает этого - сгенерировать копию, также является скрытой ссылкой аргумента MyObj obj внутри объекта MyParam (но это не формальное поле в MyParam, так что мы не можем его увидеть)

Как мы называем «showObjName», он будет использовать эту ссылку для получения соответствующего значения.

Но если мы не представим аргумент final, что приведет к ситуации, мы можем переназначить новая память (объект) к аргументу MyObj obj.

Технически нет никакого столкновения! Если нам будет позволено это сделать, ниже будет ситуация:

1. Теперь у нас есть скрытая точка [MyObj obj] к [Память A в куче], теперь живущая в объекте MyParam.
2. У нас также есть еще один [MyObj obj], который является аргументом, указывающим на [Память B в куче], теперь живущим в этом методе IsWhy.

Нет столкновения, но «CONFUSING! !» Потому что все они используют одно и то же «ссылочное имя», которое является «obj».

Чтобы избежать этого, установите его как «final», чтобы программатор не выполнял «код, подверженный ошибкам».

Поскольку Java передает копии аргументов, я считаю, что ее значимость весьма ограничена. Я предполагаю, что это происходит из эпохи C ++, где вы можете запретить ссылочный контент для изменения, выполнив const char const *. Я чувствую, что такие вещи заставляют вас полагать, что разработчику присуще глупо, как f ***, и его нужно защищать от поистине каждого персонажа, которого он набирает. Во всех смирениях я должен сказать, что я пишу очень мало ошибок, хотя я опускаю final, если только я не хочу, чтобы кто-то переоценивал мои методы и прочее ... Может быть, я просто девчонка старой школы ... : -O

Позвольте мне немного рассказать об одном случае, когда вы использовали для использования final, о котором уже упоминал Джон:

Если вы создаете анонимный внутренний класс в своем методе и используете локальная переменная (такая как параметр метода) внутри этого класса, тогда компилятор заставляет вас сделать параметр 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
    };
}

Здесь параметры from и to должны быть окончательными, поэтому они могут использоваться внутри анонимного класса.

Причина этого требования такова: локальные переменные живут в стеке, поэтому они существуют только при выполнении метода. Однако экземпляр анонимного класса возвращается из метода, поэтому он может жить намного дольше. Вы не можете сохранить стек, потому что это необходимо для последующих вызовов методов.

Таким образом, вместо того, чтобы вместо Java использовать копии этих локальных переменных в качестве скрытых переменных экземпляра в анонимный класс, вы можете увидеть их (если вы посмотрите на байтовый код). Но если они не были окончательными, можно было бы ожидать, что анонимный класс и метод, видя изменения, другой, внесенный в переменную. Чтобы сохранить иллюзию, что есть только одна переменная, а не две копии, она должна быть окончательной.

Еще одна причина добавления окончательных объявлений в параметры состоит в том, что он помогает идентифицировать переменные, которые необходимо переименовать как часть рефакторинга «Метод извлечения». Я обнаружил, что добавление окончательного значения для каждого параметра перед началом рефакторинга большого метода быстро говорит мне, есть ли какие-либо проблемы, которые мне нужно решить, прежде чем продолжить.

Однако я обычно удаляю их как лишние в конце рефакторинг.

Лично я не использую final в параметрах метода, потому что он добавляет слишком много беспорядка в списки параметров. Я предпочитаю, чтобы эти параметры метода не менялись с помощью чего-то вроде Checkstyle.

Для локальных переменных я использую final по возможности, даже позволяю Eclipse делать это автоматически в моей настройке для личных проектов.

Мне бы, конечно, понравилось нечто вроде C / C ++ const.