Как стать автором
Обновить

Почему так важна иммутабельность

Время на прочтение 5 мин
Количество просмотров 7.8K
Всего голосов 9: ↑6 и ↓3 +3
Комментарии 4

Комментарии 4

определим интерфейс PersonStorage
interface PersonStorage {
public void store(Person person);
public Person getByName(String name);
}
В таком виде интерфейс точно приведет к багам, независимо используется иммутабельность или нет. getByName на планете Земля в любой момент может выдать несколько экземпляров, поскольку полных однофамильцев достаточно. Поэтому можно возвращать только какой-нибудь
public IEnumerableOfPerson getByName(String Name)
Кроме того, Вы допускаете изменение признака Name в экземпляре класса с одной стороны, и передаете через интерфейс экземпляр неограниченному кругу пользователей без уведомления об изменении — с другой стороны. Это второй источник багов.
Про иммутабельность без упоминания ФП. Хм, вау.
С философской точки зрения, было бы правильно делить поля класса на first-class identifiers, изменение которых (скорее всего) не дает возможности дальше бизнес-логике мыслить объект до- и после изменения как эквивалентный. И second-class properties — для которых мы уверены, что объект до- и после изменения тот же самый, а какие-то его признаки изменились. При изменении first-class полей, надо создавать новый объект (в котором неплохо было бы прописать ссылку на старый — хотя бы для истории). При изменении вторичных признаков — просто меняется состояние объекта. Как это обычно бывает, однозначной трактовки — какое свойство куда отнести, нет. Это головная боль архитектора и техлида. :-) Пример из жизни: у заказа в системе есть признак «код склада». Его нельзя просто так взять и поменять. Хотя бы потому что на другом складе могут не быть доступны те же товары что и на исходном. Или на другом складе случайно может оказаться уже создан заказ с таким номером. Поэтому если пользователь хочет перенести задачу со склада на склад — на старом складе задача аннулируется, а на новом создается новая задача с теми пунктами, которые там можно исполнить. А если решили поменять комментарий у заказа — то это можно. Другой пример из жизни: у ящика с товаром есть уникальный штрихкод с ID. Его нельзя менять — просто потому что никто не может гарантировать что ваша операция по изменению ID в системе выполняется в реальности (этиктеку можно порвать, потерять, не наклеить, и т.д.). Поэтому менять ID ящика нельзя — можно только создать новый и переложить товар из старого. А вот менять location ящика — можно…
Зарегистрируйтесь на Хабре , чтобы оставить комментарий