Функциональный C#. Неизменяемые объекты | OTUS
⚡ Открываем подписку на курсы!
Проходите параллельно 3 онлайн-курса в месяц по цене одного.
Подробнее

Курсы

Программирование
Flutter Mobile Developer Подготовка к сертификации Oracle Java Programmer (OCAJP)
-8%
Алгоритмы и структуры данных
-12%
Web-разработчик на Python
-11%
Архитектура и шаблоны проектирования
-14%
JavaScript Developer. Basic Супер-интенсив «СУБД в высоконагруженных системах»
-18%
iOS-разработчик. Базовый курс
-23%
Разработчик на Spring Framework
-23%
Python Developer. Basic
-16%
C# ASP.NET Core разработчик
-18%
Разработчик программных роботов (RPA) на базе UiPath и PIX
-6%
JavaScript Developer. Professional
-9%
Android Developer. Basic
-10%
Java Developer. Professional Разработчик C# AWS для разработчиков Highload Architect Reverse-Engineering. Professional CI/CD Vue.js разработчик Agile Project Manager Нереляционные базы данных Супер - интенсив по паттернам проектирования Супер - интенсив по Kubernetes Advanced Fullstack JavaScript developer
Инфраструктура
PostgreSQL
-10%
IoT-разработчик
-12%
Administrator Linux. Professional
-11%
Базы данных
-19%
Administrator Linux.Basic
-18%
Супер-интенсив «СУБД в высоконагруженных системах»
-18%
Супер-интенсив "SQL для анализа данных"
-16%
Software Architect
-12%
Сетевой инженер AWS для разработчиков Highload Architect Разработчик голосовых ассистентов и чат-ботов Внедрение и работа в DevSecOps Администратор Linux. Виртуализация и кластеризация Нереляционные базы данных Супер-практикум по использованию и настройке GIT
Специализации Курсы в разработке Подготовительные курсы
+7 499 938-92-02

Функциональный C#. Неизменяемые объекты

Csharp_Deep_12.5-5020-759d8b.png

Самая большая проблема корпоративного ПО — сложность кода. Именно поэтому его читабельность считается одним из наиболее важных аспектов программирования. Все говорят, что код должен быть лаконичен, иначе его будет сложно и анализировать, и проверять на корректность.

Приведём пример:

// Создаём критерии поиска
var queryObject = new QueryObject<Customer>(name, page: 0, pageSize: 10);

// Ищем клиентов
IReadOnlyCollection<Customer> customers = Search(queryObject);

// Регулируем критерии, если никто не будет найден
if (customers.Count == 0)
{
    AdjustSearchCriteria(queryObject, name);
    // Поменяется ли здесь queryObject?
    Search(queryObject);
}

Итак, изменится ли объект запроса к моменту выполнения второго поиска? Возможно, да, но, возможно, и нет. И зависеть это будет от того, удастся ли нам что-либо найти после первого поиска. Кроме того, это будет зависеть и от того, поменяются ли критерии поиска после выполнения метода AdjustSearchCriteria. Говоря простым языком, мы не сможем заранее знать, поменяется ли объект запроса во 2-м поиске.

А теперь рассмотрим следующий код:

// Создаём критерии поиска
var queryObject = new QueryObject<Customer>(name, page: 0, pageSize: 10);

// Ищем клиентов
IReadOnlyCollection<Customer> customers = Search(queryObject);

if (customers.Count == 0)
{
    // Регулируем критерии, если никто не будет найден
    QueryObject<Customer> newQueryObject = AdjustSearchCriteria(queryObject, name);
    Search(newQueryObject);
}

А вот тут сразу становится всё ясно: после того, как мы ничего не найдём при первом поиске, метод AdjustSearchCriteria создаст новые критерии, которые уже станут применяться во 2-м поиске.

Подытожим: какие есть проблемы при работе со структурами данных, подвергающимися изменениям: 1. Сложно оценивать написанный код, когда мы не можем быть уверены, изменятся ли конкретные данные либо нет. 2. Довольно трудно следовать за многочисленными отсылками, когда вам потребовалось посмотреть не только на сам метод, но и на функции, вызываемые в нём. 3. Если вы пишете многопоточное приложение, отслеживание и отладка кода станут еще труднее.

Как описывать неизменяемые объекты?

Когда у вас есть относительно простой класс, вам всегда следует рассматривать вопрос о том, как сделать его неизменяемым. Данное правило коррелирует с термином Value Objects — они просты, их просто сделать неизменяемыми.

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

public class ProductPile
{
    public string ProductName { get; set; }
    public int Amount { get; set; }
    public decimal Price { get; set; }
}

Дабы сделать поля класса ProductPile неизменяемыми, отметим их доступными лишь для чтения и создадим конструктор:

public class ProductPile
{
    public string ProductName { get; private set; }
    public int Amount { get; private set; }
    public decimal Price { get; private set; }

    public ProductPile(string productName, int amount, decimal price)
    {
        Contracts.Require(!string.IsNullOrWhiteSpace(productName));
        Contracts.Require(amount >= 0);
        Contracts.Require(price > 0);

        ProductName = productName;
        Amount = amount;
        Price = price;
    }

    public ProductPile SubtractOne()
    {
        return new ProductPile(ProductName, Amount  1, Price);
    }
}

Чего нам удалось добиться такой организацией класса: 1. Мы можем не волноваться о корректности данных, т. к. проверять значение будем лишь один раз в конструкторе. 2. Теперь мы полностью уверены, что значения объектов всегда корректны. 3. Объекты автоматически становятся потокобезопасными. 4. Повысилась читаемость кода, ведь не нужно проверять, не поменялись ли значения объектов.

Ограничения в использовании

Разумеется, у всего есть цена. Высказанная идея применима в простых и маленьких классах, но неприменима в больших. Во-первых, речь идёт о производительности: если объект получается слишком большой, создание его копий каждый раз при изменениях какого-либо параметра не самым лучшим образом отразится на быстродействии приложения.

Здесь неплохим примером являются неизменяемые коллекции (immutable collections). Авторы этих коллекций учли проблемы с производительностью и добавили класс Builder, позволяющий «мутировать» и изменять коллекцию:

var builder = ImmutableList.CreateBuilder<string>();
builder.Add("1");                                   // Добавляем строки в существующий объект
ImmutableList<string> list = builder.ToImmutable();
ImmutableList<string> list2 = list.Add("2");        // Создаём объект с 2 строками

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

Итог

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

По материалам: «Functional C#: Immutability»

Не пропустите новые полезные статьи!

Спасибо за подписку!

Мы отправили вам письмо для подтверждения вашего email.
С уважением, OTUS!

Автор
0 комментариев
Для комментирования необходимо авторизоваться