Почему фабричные методы для коллекций производят неизменные экземпляры? [Дубликат]

Эффективная Java от Джошуа Блоха описывает несколько причин для написания неизменяемых классов:

• Простота - каждый класс находится только в одном состоянии
• Thread Safe - потому что состояние не может быть изменено, синхронизация не требуется
• Запись в неизменяемом стиле может привести к созданию более надежного кода. Представьте, что Струны не были неизменными; Любые методы getter, которые возвращали String, потребовали бы, чтобы реализация создала защитную копию до того, как была возвращена String, иначе клиент может случайно или злонамеренно нарушить это состояние объекта.

В целом это является хорошей практикой сделать объект неизменным, если в результате не возникнут серьезные проблемы с производительностью. В таких обстоятельствах изменяемые объекты-строители могут использоваться для создания неизменяемых объектов, например. StringBuilder

Одной из причин «необходимости» для неизменяемых классов является комбинация передачи всего по ссылке и отсутствие поддержки просмотра только для чтения объекта (например, C ++ const).

Рассмотрим простой случай класса, имеющего поддержку шаблона наблюдателя:

class Person {
    public string getName() { ... }
    public void registerForNameChange(NameChangedObserver o) { ... }
}

Если string не были неизменяемы, для класса Person было бы невозможно реализовать registerForNameChange() правильно, потому что

void foo(Person p) {
    p.getName().prepend("Mr. ");
}

В C ++ getName(), возвращающий const std::string&, имеет эффект возврата по ссылке и предотвращения доступа к мутаторам, подразумевая, что в этом контексте необязательные классы не нужны.

По неизменности вы можете быть уверены, что поведение не изменится, и вы получите дополнительное преимущество от выполнения дополнительных операций:

• Вы можете использовать несколько ядро ​​/ обработку (параллельную обработку) с помощью
• Может выполнять кэширование для дорогостоящей работы (поскольку вы уверены в том же самом результате).
• Можно легко отлаживать (поскольку история запуска больше не будет заботой)

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

Представьте, как выглядит Java, если String изменен.

Почему нерушимый класс?

После создания экземпляра объекта состояние не может быть изменено в течение жизни. Это также делает его потокобезопасным.

Примеры:

Очевидно, что String, Integer и BigDecimal и т. Д. После того, как эти значения будут созданы, нельзя изменить в течение жизни.

Пример использования: после создания объекта подключения к базе данных с его значениями конфигурации вам может не потребоваться изменить его состояние, где вы можете использовать неизменяемый класс

Непрерывные структуры данных также могут помочь при кодировании рекурсивных алгоритмов. Например, скажите, что вы пытаетесь решить проблему 3SAT . Один из способов состоит в следующем:

• Выберите неназначенную переменную.
• Дайте ей значение TRUE. Упростите экземпляр, выведя предложения, которые теперь выполняются, и повторите, чтобы решить более простой экземпляр.
• Если рекурсия в случае с TRUE не удалась, тогда вместо этого назначьте эту переменную FALSE. Упростите этот новый экземпляр и повторите его для решения.

Если у вас есть изменяемая структура для представления проблемы, тогда, когда вы упрощаете экземпляр в ветке TRUE, вам либо придется :

• Следите за всеми внесенными вами изменениями и отменяйте их все, как только осознаете, что проблема не может быть решена. У этого есть большие накладные расходы, потому что ваша рекурсия может идти довольно глубоко, и это сложно сделать.
• Сделайте копию экземпляра, а затем измените копию. Это будет медленным, потому что, если ваша рекурсия составляет несколько десятков уровней, вам нужно будет сделать много копий экземпляра.

Однако, если вы закодируете это умным способом, вы может иметь неизменяемую структуру, где любая операция возвращает обновленную (но все еще неизменяемую) версию проблемы (аналогично String.replace - она ​​не заменяет строку, просто дает вам новую). Наивный способ реализовать это состоит в том, чтобы «неизменяемая» структура просто копировала и создавала новую для любых модификаций, сводя ее ко второму решению, имея сменную, со всеми этими накладными расходами, но вы можете сделать это в более эффективным способом.

Неизменяемые классы в целом гораздо проще в проектировании, внедрении и правильном использовании. Примером является String: реализация java.lang.String значительно проще, чем реализация std::string в C ++, в основном из-за ее неизменности.

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

Обновление: Эффективное Java 2nd Edition решает эту проблему подробнее - см. Пункт 15: Минимизировать изменчивость .

См. также эти связанные сообщения:

• -технические преимущества наличия неизменяемого строкового типа
• Переход к неизменяемым объектам в Java?

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

Возьмем крайний случай: целочисленные константы. Если я напишу заявление типа «x = x + 1», я хочу быть на 100% доверенным, что число «1» не будет каким-то образом становиться 2, независимо от того, что происходит в другом месте программы.

Теперь okay, целочисленные константы не являются классом, но концепция одинаков. Предположим, что я пишу:

String customerId=getCustomerId();
String customerName=getCustomerName(customerId);
String customerBalance=getCustomerBalance(customerid);

Выглядит достаточно просто. Но если строки не были неизменными, тогда мне пришлось бы учитывать возможность того, что getCustomerName может изменить customerId, так что, когда я вызываю getCustomerBalance, я получаю баланс для другого клиента. Теперь вы можете сказать: «Почему в мире кто-то, пишущий функцию getCustomerName, изменит идентификатор? Это не имеет смысла». Но это именно то, где вы можете попасть в беду. Человек, написавший вышеуказанный код, может считать это просто очевидным, что функции не изменят параметр. Затем приходит кто-то, кто должен изменить другое использование этой функции, чтобы обрабатывать случай, когда клиент имеет несколько учетных записей под тем же именем. И он говорит: «О, вот эта удобная функция имени getCustomer, которая уже ищет имя. Я просто сделаю это, чтобы автоматически изменить идентификатор на следующую учетную запись с тем же именем и поставить ее в цикл ...» И то ваша программа начинает таинственно не работать. Будет ли это плохой стиль кодирования? Вероятно. Но это точно проблема в тех случаях, когда побочный эффект НЕ очевиден.

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

( Конечно, пользователь может назначить переменную «постоянный объект» для переменной. Кто-то может написать String s = «hello», а затем написать s = «goodbye»; если я не сделаю переменную final, я не могу быть уверен, что он не изменяется в моем собственном блоке кода. Как и целочисленные константы, заверить меня, что «1» всегда совпадает с номером, но не «x = 1» никогда не будет изменен, написав «x = 2». быть уверенным в том, что если у меня есть дескриптор неизменяемого объекта, то никакая функция, которую я передаю, не может изменить его на мне, или что если я сделаю две копии этого, то изменение переменной, содержащей одну копию, не изменит другую И др.

Существуют разные причины неизменности:

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

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

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

Если у меня есть изменяемый объект, я не уверен, какова его ценность, если он когда-либо используется за пределами моей непосредственной области. Предположим, я создаю MyMutableObject в локальных переменных метода, заполняю их значениями, а затем передаю их еще пяти методам. Любой из этих методов может изменить состояние моего объекта, поэтому должно произойти одно из двух:

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

Первое затрудняет рассуждение о моем коде. Во-вторых, мой код вписывается в производительность - я в любом случае имитирую неизменяемый объект с семантикой copy-on-write, но все время делаю это независимо от того, действительно ли вызываемые методы изменяют состояние моего объекта.

Если я вместо этого использую MyImmutableObject, я могу быть уверен, что то, что я установил, - это то, что значения будут для жизни моего метода. На расстоянии нет «жутких действий», которые меняют его из-под меня, и мне не нужно делать защитные копии моего объекта, прежде чем ссылаться на пять других методов. Если другие методы хотят изменить вещи для своих целей, они должны сделать копию & ndash; но они делают это только в том случае, если им действительно нужно сделать копию (в отличие от моего выполнения перед каждым вызовом внешних методов). Я избавляю себя от умственных способностей отслеживать методы, которые могут быть даже не в моем текущем исходном файле, и я избавляю систему от накладных расходов, бесконечно делая ненужные защитные копии на всякий случай.

(Если я пойду вне мира Java и, скажем, в мире C ++, я могу стать еще более сложным. Я могу сделать объекты похожими, как будто они изменяемы, но за кулисами делают их прозрачно клонированными при любом изменении состояния & mdash , это copy-on-write & mdash, причем никто не мудрее.)

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