объектов, как здесь?
https://www.geeksforgeeks.org/create-immutable-class-java/
Такой подход годится как защита от клиентского кода, который пытается поменять состояние этого объекта.
Считаю, что этот подход плохой и не стоит так делать никогда, потому что это создает оверхед использования ресурсов, когда клиентский код сам по себе не изменяет этот объект.
Думаю, что обеспечивать иммутабельность лучше на стороне клиентского кода так, чтоб вообще не модифицировать состояние объекта.
Какие мысли у вас по этому поводу?
Вот ещё додумал, что подход, описанный в статье, годится для защиты от дурака. Например, когда нужно обеспечить иммутабельность объекта из библиотеки.
Ты читал статью?
Так статья говно примитивное и несодержательное, что там читать Твоя позиция в общем-то тоже сводится к "не разобрался"
Да, этот подход хороший. Пример примитивный. Инкапсуляция — это не только и не столько сокрытие реализации, сколько защита состояния. И если важно ее предоставить, то это надо делать. И дело даже не в защите от дурака. Так, например, не стоит отдавать лишнего вовне.
Стать не очень. Гугли valueobject pattern по этой теме
Похоже, что я забыл указать на один пункт из статьи, о чём собственно речь. Пункт о deep copy в конструкторе и deep copy в геттере. Эти deep copy выполняются каждый раз вне зависимости от того, что клиентский код 1)дурака собственно намерен попытаться изменить этот объект (в этом случае ок) 2)НЕ намерен изменить этот объект Одно из двух. Во втором случае deep copy избыточен
Ну в статье имплементация говно. Если у тебя есть иммутабельные объекты, делай поля паблик файнал, всё.
Обсуждают сегодня