Почему ключевое слово 'final' так мало используется в отрасли? [закрыто]

С тех пор как я обнаружил силу finalключевого слова в Java несколько лет назад, это помогло мне сделать мои коды более читабельными, поскольку люди могут легко видеть, что является переменными только для чтения. Он также может немного увеличить JIT, и, хотя он очень ограничен, он не может нанести вред, особенно при нацеливании на встраиваемые устройства, такие как платформы Android.

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

Однако, просматривая некоторые исходные коды JDK, я никогда не сталкивался с этим ключевым словом ни для классов, ни для методов, ни для переменных. То же самое относится к различным системам, которые я должен был рассмотреть.

Есть ли причина? Это общая парадигма дизайна, позволяющая сделать все изменчивым изнутри?

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

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

В отличие от того, что вы видите в Java, в мире .NET, я много раз слышал аргумент, что предложения должны быть sealed(аналогично окончательному применению к классу) по умолчанию, и что разработчик должен явно отключить печать Это.

Проблема с использованием finalдля передачи того, что что-то доступно только для чтения, заключается в том, что оно действительно работает только для примитивных типов, таких как intи charт. Д. Все объекты в Java фактически упоминаются с использованием (своего рода) указателя. В результате, когда вы используете finalключевое слово для объекта, вы только говорите, что ссылка доступна только для чтения, сам объект по-прежнему изменчив.

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

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

public void someMethod(FancyObject myObject) {
    myObject = new FancyObject();
    myObject.setProperty(7);
}
...
public static void main(final String[] args) {
    ...
    FancyObject myObject = new FancyObject();
    someOtherObject.someMethod(myObject);
    myObject.getProperty(); // Not 7!
}

В этом примере кажется очевидным, почему это не работает, но если someMethod(FancyObject)это большое и сложное замешательство, может последовать. Почему бы не избежать этого?

Это также часть стандартов кодирования Sun (или Oracle, я думаю, сейчас).

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

Некоторые другие языки, такие как scala, значительно упрощают создание окончательных объявлений ( val ). В этих языках окончательные объявления могут быть более распространенными, чем переменные.

Обратите внимание, что существует много разных вариантов использования ключевого слова final. Ваш пост в основном охватывает пункты 2 и 3.

1. финальные классы (JLS 8.1.1.2)
2. окончательные поля (JLS 8.3.1.2)
3. окончательные методы (JLS 8.4.3.3)
4. окончательные переменные (JLS 4.12.4)

Начнем с того, что официальные соглашения по Java Code не поддерживают и не запрещают конкретное использование final. То есть разработчики JDK могут свободно выбирать способ, который они предпочитают.

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

• Скажем, в одном из моих проектов , мы могли позволить себе потратить в среднем за день на 100 , как строк кода. В этом проекте у меня было четкое восприятие finalкак мусора, который просто затемняет вещи, которые уже достаточно четко выражены в коде. Похоже, что разработчики JDK тоже попадают в эту категорию.
   
  С другой стороны, это было совершенно противоположно в другом проекте, где мы потратили в среднем час на 100 строк кода. Там я обнаружил, что стреляю finalкак из автомата в своем и чужом коде - просто потому, что это был самый быстрый способ обнаружить намерение парня, который написал это до меня, и, аналогично, самый быстрый способ сообщить о своем намерении парень, который будет работать над моим кодом позже.

Это также может немного увеличить JIT, и хотя оно очень ограничено, оно не может повредить

Рассуждения, как указано выше, скользкие. Преждевременная оптимизация может нанести вред; Дональд Кнут заходит так далеко, что называет его «корнем всего зла» . Не позволяйте этому заманить вас в ловушку. Напиши тупой код .

Недавно я обнаружил радость функции «Сохранить действия» в Eclipse IDE. Я могу заставить его переформатировать мой код, вставить недостающие @Overrideаннотации и сделать некоторые изящные вещи, такие как удаление ненужных скобок в выражениях или finalавтоматическое размещение ключевых слов везде при каждом нажатии ctrl + S. Я активировал некоторые из этих триггеров, и, мальчик, это очень помогает!

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

• Я намеревался переопределить метод, но аннотация не появилась, когда я нажал ctrl + s? - возможно, я где-то облажался типов параметров!
• Некоторые скобки были удалены из кода при сохранении? - может быть, это логическое выражение слишком сложно для программиста, чтобы быстро обойтись. Иначе, зачем мне добавлять эти скобки в первую очередь?
• Этот параметр или локальная переменная не final. Есть ли у изменить его значение?

Оказалось, что чем меньше переменные меняются, тем меньше у меня проблем во время отладки. Сколько раз вы следили за значением некоторой переменной только для того, чтобы обнаружить, что она каким-то образом меняется, скажем, с 5 на 7? "Как, черт возьми, это может быть ?!" Вы спрашиваете себя и тратите следующие пару часов, входя и выходя из бесчисленных методов, чтобы выяснить, что вы допустили ошибку в своей логике. И чтобы исправить это, вам нужно добавить еще один флаг, пару условий и тщательно изменить некоторые значения здесь и там.

О, я ненавижу отладку! Каждый раз, когда я запускаю отладчик, я чувствую, что мое время истекает, и мне отчаянно нужно это время, чтобы хотя бы некоторые мои детские мечты сбылись! К черту отладку! finalОзначает, что больше нет таинственных изменений стоимости. Больше finals => меньше надуманных частей в моем коде => меньше ошибок => больше времени, чтобы делать хорошие вещи!

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

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