Всегда ли нужно стремиться к неизменяемости объектов?

Question

[Никита]

Делал лабораторную по ооп на c#, сначала сделал без неизменяемости: для полей, которые нужно изменять оставил сеттер, для остальных - только геттер. Но преподаватель попросил сделать объекты неизменяемыми и сделать это с помощью билдера. Сделал, но код стал менее понятным, и тесты писать стало труднее, так как при попытке изменить объект создавался новый и приходилось искать этот новый объект, чтобы продолжить работу с ним. Ну и сам вопрос: в каких случаях лучше делать объекты неизменяемыми, а в каких можно обойтись ограничением некоторых полей?

Comments

[Hemul GM]

Препод походу функциональщиной увлекается сильно. Беги от него

[Alexandroppolus]

Hemul GM, иммутабельность ещё не ФП. Может просто у преподов есть директива научить в иммутабельный подход

[Hemul GM]

Alexandroppolus, иммутабельность и сама концепция ООП - можно сказать противоречащие вещи. Да, можно натянуть сову на глобус, но это не будет означать, что страна США выглядит как анус этой самой совы.

Объекты генерируют события, меняют своё состояние в зависимости от действий над ними, изменяют свои свойства. Вы только представьте. У вас есть класс окна. И вы хотите изменить заголовок окна. Что для этого нужно будет сделать? Ужас же

[Alexandroppolus]

Hemul GM, ну например строки в js или c# - это неизменяемые объекты. Потому что разработчики языков решили, что так будет удобнее в большинстве случаев.
Опять же, в классе вполне может быть какое-то поле, содержащее неизменяемый объект (да хотя бы те же строки, но необязательно). Т.е. мы можем присваивать в это поле, но не можем менять что-то в объекте. Это комбинированный подход, где есть как мутабельность, так и иммутабельность.
Такие кейсы никак не противоречат ООП.

Answer 1

[Alexandroppolus]

У неизменяемых объектов есть свои плюсы. Во первых, их легче сравнивать: вместо сравнения всех полей (рекурсивно) сравниваем только две корневые ссылки на объекты. Во вторых, можно расшарить некоторые внутренние структуры данных. Например, строка во многих ЯП (C#, Java, JS) - это неизменяемый объект. И в JS есть оптимизация - когда берем подстроку от строки, то используем тот же буфер данных. В случае изменяемой строки такой фокус бы не прокатил.

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

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

Comments

[Никита]

Спасибо!

[Никита]

Правда, непонятен 1 пункт про сравнение

[Vamp]

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

[Никита]

Vamp, Спасибо