Зачем отмечать локальные переменные и параметры метода как "окончательные" в Java? [закрытый]


в Java вы можете квалифицировать локальные переменные и параметры метода с помощью ключевого слова final.

public static void foo(final int x) {
  final String qwerty = "bar"; 
}

Это приводит к невозможности переназначить x и qwerty в теле метода.

эта практика подталкивает ваш код в направлении неизменности, которая обычно считается плюсом. Но он также имеет тенденцию загромождать код с "окончательным" отображением повсюду. Каково Ваше мнение о конечном ключевом слове для локальных переменных и параметров метода в Ява?

12 57

12 ответов:

вы должны попытаться сделать это, когда это уместно. Кроме того, чтобы предупредить вас, когда вы "случайно" пытаетесь изменить значение, он предоставляет компилятору информацию, которая может привести к лучшей оптимизации файла класса. Это один из пунктов в книге "Hardcore Java" Роберта Симмонса-младшего.на самом деле, книга тратит всю свою вторую главу на использование final для содействия оптимизации и предотвращения логических ошибок. Инструменты статического анализа, такие как PMD и встроенный в СА Eclipse флаг эти виды случаев по этой причине.

мое личное мнение, что это пустая трата времени. Я считаю, что визуальный беспорядок и добавил детализации не стоит.

Я никогда не был в ситуации, когда я переназначил (помните, это не делает объекты неизменяемыми, все это означает, что вы не можете переназначить другую ссылку на переменную) переменную по ошибке.

но, конечно, это все личные предпочтения ;-)

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

отсюда не использование final делает ваш код менее читаемым и поддерживаемым сам по себе:)

конечные локальные переменные зависят от намерения и менее важны с моей точки зрения. Зависит о том, что происходит.

в случае локальных переменных, я стараюсь избежать этого. Это вызывает визуальный беспорядок и, как правило, не требуется - функция должна быть достаточно короткой или сосредоточиться на одном воздействии, чтобы вы быстро увидели, что вы изменяете то, что не должно быть.

в случае магических чисел, я бы поставил их в качестве постоянного частного поля в любом случае, а не в коде.

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

из-за (Иногда) запутанной природы Java "пройдите по ссылке " поведение я определенно согласен с завершением параметра var.

завершение локального var кажется несколько излишним IMO.

да сделай это.

речь идет о читаемости. Легче рассуждать о возможных состояниях программы, когда вы знаете, что переменные назначаются один и только один раз.

достойной альтернативой является включение предупреждения IDE при назначении параметра или при назначении переменной (кроме переменной цикла) более одного раза.

финал имеет три веские причины:

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

Как метода, локальные переменные и параметры не должны быть объявлены окончательными. Как уже говорили другие, это загромождает код становления менее читаемый с очень небольшим усилием для оптимизации производительности компилятора, это не является реальной причиной для большинства фрагментов кода.

хотя это создает немного беспорядка, стоит положить final. Ides например затмение может автоматически поставить final Если вы настроите его для этого.

создание локальных переменных и параметров метода final важно, если вы хотите передать эти параметры в анонимные классы - например, вы создаете экземпляр анонимного потока и хотите получить доступ к этим параметрам в теле метода run ().

кроме того, я не уверен в преимуществах производительности w.r.t лучшей производительности за счет оптимизации компилятора. Это зависит от конкретной реализации компилятора, хочет ли он оптимизировать ее вообще...

будет хорошо знать о любой статистике производительности от использования final ...

зачем тебе это нужно? Вы написали метод, поэтому любой, кто его модифицирует, всегда может удалить последнее ключевое слово из qwerty и переназначить его. Что касается сигнатуры метода, то же самое рассуждение, хотя я не уверен, что он будет делать с подклассами вашего класса... они могут наследовать конечный параметр, и даже если они переопределяют метод, не смогут де-завершить x. попробуйте и узнайте, будет ли он работать.

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

Edit

в ответ на комментарий я добавлю, что если вы видите проблемы с производительностью, то ваши локальные переменные и параметры могут позволить компилятор для оптимизации кода лучше. Однако, с точки зрения неизменности вашего кода, я стою на своем первоначальном утверждении.

Я позволяю Eclipse делать это за меня, когда они используются в анонимном классе, который увеличивается из-за моего использования API Google Collection.

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

параметры не являются окончательными, так как у нас есть Checkstyle-Check, который проверяет переназначение параметров. Конечно, никто никогда не захочет переназначить переменную параметр.