Поверьте мне, я знаю о способах защиты от изменений, включая и тот, когда на каждую единицу данных расходуется до нескольких десятков байт дополнительно (как пример, коллекции-контейнеры примитивных типов).
Если вы знакомы с языком C++, то должны ощущать разницу между, к примеру, const int * ptr; и int * const ptr;
В Java, к моему сожалению, для примитивов есть только первый способ, а для ссылок — только второй. И, что печально, оба они имеют одинаковое представление: final type variable;
Однако во всё том же C++ есть и третий вариант: const int * const ptr;.
Было бы не плохо, если бы в Java можно было бы также иметь все три варианта: final type для неизменяемых ссылок, const type для неизменяемых значений, final const type и/или const final type для неизменяемых и ссылок, и значений.
В целях обратной совместимости для примитивных типов final и const могли бы быть синонимами.
Переложить на компилятор контроль за соблюдением константности сущностей — гора с плеч для рядового программиста, особенно если функциональные принципы программирования стоят не на последнем месте.
Об этом я, вероятно невразумительно, пытался объяснить в пятом пункте этой статьи.
Красота, как говорится, требует жертв. Это не для узких мест, а вообще, как мне кажется, профайлинг и рефакторинг решает подобные проблемы.
То, что я поведал, более относится к возможностям, чем к потребностям. Кто, программируя для Java, печётся о таких мелочах? Возьмите даже функциональные и не только языки, которые компилируются в байт-код JVM. Их замыкания пока (надеюсь) реализуются именно посредством анонимных классов. И никто особо не жалуется, поскольку бесполезно:)
Если вы знакомы с языком C++, то должны ощущать разницу между, к примеру, const int * ptr; и int * const ptr;
В Java, к моему сожалению, для примитивов есть только первый способ, а для ссылок — только второй. И, что печально, оба они имеют одинаковое представление: final type variable;
Однако во всё том же C++ есть и третий вариант:
const int * const ptr;.
Было бы не плохо, если бы в Java можно было бы также иметь все три варианта:
final type для неизменяемых ссылок,
const type для неизменяемых значений,
final const type и/или const final type для неизменяемых и ссылок, и значений.
В целях обратной совместимости для примитивных типов final и const могли бы быть синонимами.
Переложить на компилятор контроль за соблюдением константности сущностей — гора с плеч для рядового программиста, особенно если функциональные принципы программирования стоят не на последнем месте.
Об этом я, вероятно невразумительно, пытался объяснить в пятом пункте этой статьи.
То, что я поведал, более относится к возможностям, чем к потребностям. Кто, программируя для Java, печётся о таких мелочах? Возьмите даже функциональные и не только языки, которые компилируются в байт-код JVM. Их замыкания пока (надеюсь) реализуются именно посредством анонимных классов. И никто особо не жалуется, поскольку бесполезно:)