Есть ли техническая причина, которая препятствует тому, чтобы final в Java был таким же строгим, как const в C ++?

Question

В C ++ можно использовать ключевое слово const, чтобы указать, является ли указатель на данные или сами данные постоянными (или обоими), т. Е.

const SomeClass* p; // Данные постоянны

или

SomeClass* const p; // Указатель постоянен

или

const SomeClass* const p; // Оба константы

In Java последнее ключевое слово гораздо более ограничено:

final SomeClass o; // Ссылка постоянна, объект можно изменить

Я всегда удивлялся, почему Java в этом смысле более ограничен, чем C ++ уважать. Было ли это решение, принятое проектировщиками языков (что могло быть так же хорошо решено иным образом), или есть техническая причина, препятствующая этому?

Имеет ли тот факт, что Java объекты управляются сборщик мусора имеет здесь влияние?

Answer 1

Первая причина в том, что Java final не служит той же цели, что и C ++ const. Хорошо для цели, которой оно служит , что должно быть семантическим c ограничением на иерархию объектно-ориентированных классов, чтобы способствовать правильному проектированию такой иерархии. Который не имеет ничего общего с неспособностью изменить значение / состояние класса.

Вторая причина в том, что не было ничего, что помешало бы Java иметь "постоянную" особенность некоторых вид. Но изначально он был разработан для очень ограниченного варианта использования (ограниченного по сравнению с текущими вариантами использования), который был предназначен для встроенных вычислений на крошечных устройствах с ограниченными ресурсами простым способом. И с учетом этого варианта использования одной из основных первоначальных целей была простота программирования кода, простота программирования виртуальной машины, простота программирования компилятора и так далее. и «const» -ishness была сложностью, в которой они не нуждались в то время.

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

И есть чувство (оправданное), что многое из того, что вы получаете, декларируя "const" -шланчность, вы можете получить с другими объектно-ориентированными функциями, которые в языке, например, наличие геттеров для полей, но не сеттеров.

Так что нет никаких оснований для того, чтобы в языке / VM / framework не было "const" -ishness, за исключением того, что в нем нет Это считалось важным, как и другие вещи, которые нужно выработать, и в языке есть обходные пути.

Но люди добавили "const" -ishness к Java - просто вне языкового стандарта. Посмотрите различные библиотеки и инструменты для создания «неизменяемых объектов», чтобы увидеть, что можно сделать.

(И чтобы ответить на ваш последний вопрос: это не имеет ничего общего с G C.)