Было бы хорошей идеей неизменное ключевое слово в Java? - PullRequest
3 голосов
/ 13 января 2011

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

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

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

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

Ответы [ 4 ]

4 голосов
/ 13 января 2011

В общем, неизменяемые объекты должны быть предпочтительнее, чем объекты с состоянием, и в настоящее время довольно сложно создать неизменяемый объект в Java .Фактически, большинство языков OO плохо поддерживают неизменяемые объекты, в то время как большинство функциональных языков принимают их как должное, такие как F #, Haskell и Clojure.

Добавление неизменяемого ключевого слова в Java может сделать код ...

  • Проще писать.Не вмешивайтесь в final и private, не добавляйте случайно метод, делающий класс изменяемым, и, возможно, не помечайте вручную класс final (подклассы могут добавлять изменяемое состояние ).
  • Легче читать.Вам не нужно говорить, что класс неизменен на английском , вы можете сказать это в самом коде.Неизменяемое ключевое слово - хороший шаг к самодокументируемому коду.
  • Быстрее (теоретически).Чем больше компилятор знает о вашем коде, тем больше он может оптимизировать.Без этого ключевого слова каждый вызов new ImmutableFoo(1, 2, 3) должен создавать новый объект, если только компилятор не докажет, что ваш класс не может быть мутирован.Если ImmutableFoo было отмечено ключевым словом immutable, каждый такой вызов может возвращать один и тот же объект.Я почти уверен, что new должен всегда создавать новый объект, что делает эту точку недействительной, но эффективная связь с компилятором все еще хорошая вещь.

Классы дел в Scala похожи на неизменяемое ключевое слово. Неизменное ключевое слово также рассматривалось в C # 5 .

4 голосов
/ 13 января 2011

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

  • Что если в вашем последнем классе также есть загруженные ленивые поля? Требуется дополнительная поддержка для маркировки таких полей как неизменных и ленивых.

  • Взглянув на java.lang.String с его массивом символов [], как компилятор мог действительно знать, что он неизменен? Всем известно, что string - это другой, но другой подобный класс может очень легко включать метод, который обновляет массив. Дальнейшая поддержка должна будет проверить, что после того, как поле было установлено, никакая другая инструкция не может «записать» в массив. Вскоре это становится очень сложной проблемой.

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

1 голос
/ 13 января 2011

ИМХО, объектно-ориентированные среды (Java, .net и т. Д.) Должны включать больше типов массивов: изменяемый массив, неизменяемый массив, ссылки на изменяемые массивы, ссылки на неизменяемые массивы и ссылки на массивы только для чтения (ссылка только для чтения может указывать либо на изменяемый, либо на неизменяемый массив, но ни в одном случае не разрешит запись). Без неизменяемого типа массива трудно создать множество эффективных типов таким образом, чтобы можно было доказать, что он неизменный.

1 голос
/ 13 января 2011

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...