Должны ли поля быть явно окончательными, чтобы иметь «правильный» неизменяемый объект?

Question

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

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

Наличие окончательного поля дает очевидное преимущество предотвращения ошибок реализации (например, позволяет коду сохранять ссылку на строитель и «строить» объект несколько раз, в то же время мутируя существующий объект), но имея хранилище Builder его данные внутри объекта по мере его создания выглядят как DRYer.

Вопрос: Предположим, что Builder не пропустил объект раньше и перестает модифицировать объект после его создания (например, установив его ссылку на объект как нуль), на самом деле что-то получилось (например, улучшенная безопасность потоков) в «неизменности» объекта, если поля объекта были сделаны окончательными?

Answer 1

Да, вы получаете «безопасность потока» от полей final. То есть значение, присвоенное полем final во время строительства, гарантируется, что оно будет видимым для всех потоков. Другой альтернативой безопасности потоков является объявление полей volatile, но тогда вы получаете высокие накладные расходы при каждом считывании & hellip; и смущает любого, кто смотрит на ваш класс, и задается вопросом, почему поля этого «неизменного» класса отмечены «неустойчивыми».

Маркировка полей final является наиболее правильной технически и наиболее четко отражает ваше намерение. К сожалению, это делает шаблон строителя очень громоздким. Я думаю, что должно быть возможно создать обработчик аннотации, чтобы синтезировать строитель для неизменяемого класса, как это делает Project Lombok с сеттерами и геттерами. Реальной работой будет поддержка IDE, необходимая для того, чтобы вы могли кодировать против строителей, которые на самом деле не существуют.

Answer 2

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

Фактически, если ваша инкапсуляция правильная, вы можете фактически изменить внутреннее состояние и продолжать успешно работать как «неизменный» объект. Примером может быть какая-то ленивая оценка или кэширование структур данных.

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

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

Answer 3

Я думаю, вам просто нужно будет рассмотреть окружающую среду, в которой он работает, и решить, опасны ли рамки, которые используют отражение для управления объектами.

Можно было бы составить сценарий с нечеткой ситуацией, когда предположительно неизменяемый объект будет сбиваться с помощью атаки на POST-инъекцию из-за структуры привязки к веб-интерфейсу, которая настроена на использование рефлексии вместо bean-сеттеров.

Answer 4

У вас определенно может быть неизменяемый объект с не последними полями.

Например, см. Java 1.6 реализацию java.lang.String.

Answer 5

Комментарий: @erickson

Как что:

 
class X { volatile int i, j; } 
X y; 

// thread A: 
X x = new X; 
x.i = 1; 
x.j = 2; 
y = x; 

// thread B: 
if (y != null) { 
    a = y.i; 
    b = y.j; 
} 

?