Используйте объекты-значения

Фуллстек-разработчик Springer Nature Луис Соареш (Luís Soares) описал достоинства объектов-значений на примере языка Kotlin. Но объекты-значения могут быть такими же полезными и в других языках! Доказательства — в нашем переводе статьи: разработчик Noveo Ян перевёл её на русский, заменив язык примеров на РНР.

Как убедиться, что два разных компонента «говорят» на одном языке? Как проверить, не разбросаны ли у вас по проекту некорректные данные? Что говорят обычные строки или целые числа о вашей предметной области?

Например, в Java (или PHP, начиная с версии 8.1, — прим. пер.) перечисления являются встроенными в язык объектами-значениями. Тем не менее, они не подходят для произвольного количества значений (и являются скорее технической деталью реализации — прим. пер.). Типичными объектами-значениями являются: адрес электронной почты, пароль, локаль, номер телефона, деньги, IP-адрес, URL, идентификатор сущности, рейтинг, путь до файла, точка, цвет, дата, диапазон дат, расстояние.

Объекты-значения часто упоминаются в связке с предметно-ориентированным проектированием. Давайте рассмотрим их некоторые характеристики на примере языка программирования PHP.

Контейнер данных

Объект-значение — это контейнер произвольных данных:

			class Email
{
    public function __construct(private string $email) {}

    public function getValue(): string
    {
        return $this->email;
    }
}
		

Непосредственное значение хранится внутри класса.

Обычно объект-значение хранит в себе какое-то одно конкретное значение, но вполне может и больше. Например, цвет в формате RGBA содержит четыре целых числа, а точка в пространстве — три десятичных. Так и между параметрами функции часто может существовать логическая связь. В таком случае их стоит выделить в отдельный класс. Плюсы такого подхода:

• Меньшее количество аргументов функции;
• Явная и однозначная связь между параметрами;
• Ярче выражена идея того, что делает код.

Просто сравните:

			function distance(float $x1, float $x2, float $y1, float $y2): float
{
    //
}

function distance(Point $p1, Point $p2): float
{
    //
}
		

В некоторых языках программирования также возможна передача объектов-значений по значению, а не по ссылке. Объекты-значения — спасение от «одержимости примитивами», реальное значение в них — лишь деталь реализации. Например, если вы захотите поменять тип идентификатора сущности User с целого числа на строку, то после этого вам не придётся изменять классы, использующие этот идентификатор, или сигнатуры вроде таких:

			function findById(UserId $userId): ?User
{
    // все вызовы метода останутся без изменений
}
		

Одинаковое значение? Значит равны

Доставая витаминку из упаковки, мы обычно не задумываемся о том, чем одна из них отличается от другой. Так и с объектами-значениями. Пока они несут в себе одинаковое внутреннее значение (или несколько значений), они и сами всегда будут считаться одинаковыми. Даже если ссылки указывают на разное место в оперативной памяти:

			class Email
{
    public function __construct(private string $email) {}

    public function getValue(): string
    {
        return $this->email;
    }

    public function equals(Email $other): bool
    {
        return $this === $other || $this->email === $other->email;
    }
}

// Тест

use PHPUnit\Framework\TestCase;

class EmailTest extends TestCase
{
    public function testEquals()
    {
        $emailOne = new Email('foo@bar.com');
        $emailTwo = new Email('foo@bar.com'); 

        static::assertTrue($emailOne->equals($emailTwo));
    }
}
		

Объекты, равные по значению свойств, называются объектами-значениями, — Мартин Фаулер

Неизменяемость

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

В этом параграфе я решил показать другой пример, чтобы не повторяться с Email, — прим. пер.

Возьмем для примера точку на плоскости. Логично, что однажды созданная точка не может быть изменена, потому что при любом изменении координат это будет уже совершенно другая точка!

			class Point
{
    public function __construct(private int $x, private int $y) {}

    public function getX(): int
    {
        return $this->x;
    }

    public function getY(): int
    {
        return $this->y;
    }

    public function equals(Point $other): bool
    {
        return $this === $other ||
               ($this->x === $other->x && $this->y === $other->y);
    }
}
		

Обратите внимание, что в этом примере мы определили только геттеры — методы доступа к координатам точки.

Неизменяемые значения можно свободно передавать из функции в функцию без надобности создавать копии. При этом конкурентный доступ к таким значениям безопасен по умолчанию. Тестирование сводится к созданию отдельных объектов класса через конструктор и проверку возвращаемых значений его методов. Неизменяемые объекты позволяют писать функции без побочных эффектов, а те, в свою очередь, имеют собственные преимущества, — «Объекты-значения», Флориан Бенц

Без идентичности и без истории

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

Сущность обладает идентичностью и жизненным циклом за счет свойств и их изменения со временем. Индивидуальность объекта-значения заключается в его данных. А поскольку эти данные не подвержены изменениям, можно сказать, что собственной «жизни» у объектов-значений нет.

Объектно-ориентированное программирование простым языком — объясняют эксперты

Сущности пребывают, так сказать, в континууме. Они обладают историей изменений в течение времени жизни, даже если мы эту историю нигде не храним. Объекты-значения, напротив, имеют нулевую продолжительность жизни. Мы с легкостью создаем и уничтожаем их. Мы не храним такие значения отдельно. Единственный способ их сохранить — сделать частью сущности, — «Сущность vs Объект-значение», Владимир Хориков

Самопроверка

Как убедиться, например, в том, что все телефонные номера в приложении корректны? С помощью объектов-значений можно предотвратить существование некорректных данных в принципе. Валидация данных на этапе создания объекта способствует инкапсуляции соответствующей логики в одном месте вместо её разброса по всему приложению. Зачастую подобная логика также несёт в себе ценную информацию о предметной области.

			final class Email
{
    private string $email;

    public function __construct(string $email)
    {
        if (!preg_match('/^\S+@\S+$/', $email)) {
            throw new InvalidEmailException(sprintf(
"'%s' is not a valid e-mail address",
$email
 ));
        }

        $this->email = $email;
    }

    public function getValue(): string
    {
        return $this->email;
    }
}


// Тесты

use PHPUnit\Framework\TestCase;

final class EmailTest extends TestCase
{
    public function testConstructorShouldThrowException(): void
    {
        $this->expectException(InvalidEmailException::class);

        new Email('not.an.email');
    }

    public function testConstructorShouldCreateValidEmail(): void
    {
        $email = new Email('some@email.com');

        self::assertEquals('some@email.com', $email->getValue());
    }
}
		

Могут содержать логику

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

			final class Email
{
    private string $email;

    // ...конструктор с проверками и т.д.

    public function getHost(): string
    {
        return substr($this->email, strpos($this->email, '@') + 1);
    }
}

// Тесты

use PHPUnit\Framework\TestCase;

final class EmailTest extends TestCase
{
    public function testGetHost(): void
    {
        $email = new Email('some@email.com');

        self::assertEquals('email.com', $email->getHost());
    }
}
		

В оригинальной статье следующий пример с точками использует перегрузку операторов в Kotlin. Так как в PHP такой возможности нет, мы определим метод add, — прим. пер.:

			final class Point
{
    public function __construct(private int $x, private int $y) {}

    public function add(Point $other): Point
    {
        return new Point(
            $this->x + $other->x,
            $this->y + $other->y
        );
    }

    public function equals(Point $other): bool
    {
        return $this === $other ||
        ($this->x === $other->x && $this->y === $other->y);
    }
}

// Тесты

use PHPUnit\Framework\TestCase;

final class PointTest extends TestCase
{
    public function testAdd(): void
    {
        self::assertTrue(
            (new Point(1, 2))
                ->add(new Point(-4, 7))
                ->equals(new Point(-3, 9))
        );
    }
}
		

Несут смысл

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

Давайте рассмотрим несколько примеров. Пусть у нас есть сущность Customer. Большинство её свойств можно представить в виде объектов-значений:

			// с использованием примитивных типов

class Customer
{
    private int $id;
    private string $email;
    private string $salutation;
    private string $firstName;
    private string $lastName;
    private string $language;
    private float $createdAt;
}

// с использованием объектов-значений

final class CustomerId
{
    //
}

final class Email
{
    //
}

final class Salutation
{
    private function __construct(private string $salutation) {}

    public static function mr(): self
    {
        return new self('Mr');
    }

    public static function ms(): self
    {
        return new self('Ms');
    }

    public function getSalutation(): string
    {
        return $this->salutation;
    }
}

final class Name
{
    public function __construct(private string $name) {}

    public function first(): string
    {
        return explode(' ', $this->name)[0];
    }

    public function last(): string
    {
        return explode(' ', $this->name)[1];
    }
}

final class Locale
{
    public function __construct(private string $locale) {}

    public function getValue(): string
    {
        return $this->locale;
    }
}

class Customer
{
    private CustomerId $id;
    private Email $email;
    private Salutation $salutation;
    private Name $name;
    private Locale $language;
    private \DateTimeImmutable $createdAt;
}

Далее, сравните сигнатуры:

function notifyClient(string $email)

vs

function notifyClient(Email $recipient)
		

Параметр в первой сигнатуре напоминает мне венгерскую нотацию, плохой стиль программирования на современном языке. Вторая сигнатура фокусируется на смысле параметра — поэтому указание типа в его названии излишне.

Сравните вызовы ниже — второй из них не допускает неясности относительно порядка аргументов:

			sendSms('test123', 'text');

vs

sendSms(new UserId('test123'), 'text');
		

Объекты-значения ещё более важны в функциональных языках программирования, так как там очень часто используются лямбда-выражения. Также объекты-значения улучшают читабельность кода в языках с поддержкой обобщенного программирования (пример на языке программирования Kotlin, — прим. пер.):

			val articleMappings: Map<String, String>

vs

val articleMappings: Map<ArticleCategory, Region>
		

Объекты-значения явно выражают предметную область. Пример — обертка Money вместо двух полей типа BigDecimal и String <…>. Читатели кода поймут, что речь идёт о деньгах, а разработчики не смогут передавать в методы нечто, не представляющее собой деньги. Помимо этого, такая обертка может содержать валидацию, что значит дополнительные сведения о предметной области и повышение безопасности, — «Объект-значения», Флориан Бенц

Бонус: нормализация

Вероятно, однажды вам понадобится снизить строгость относительно пользовательского ввода ради гибкости и во избежание странных багов. Например, вы могли бы автоматически конвертировать ” John.Doe@Gmail.com ” в “john.doe@gmail.com”:

			final class Email
{
    private string $email;

    public function __construct(string $email)
    {
        $email = trim(mb_strtolower($email));

        if (!preg_match('/^\S+@\S+$/', $email)) {
            throw new InvalidEmailException(sprintf("'%s' is not a valid e-mail address", $email));
        }

        $this->email = $email;
    }

    public function getValue(): string
    {
        return $this->email;
    }

    public function equals(Email $other): bool
    {
        return $this === $other || $this->email === $other->email;
    }
}

// Тесты

use PHPUnit\Framework\TestCase;

final class EmailTest extends TestCase
{
    public function testEquals(): void
    {
        $emailOne = new Email('lower@vw.org');

        static::assertTrue($emailOne->equals(new Email('lower@vw.org')));
        static::assertTrue($emailOne->equals(new Email(' Lower@vw.org  ')));
    }
}
		

Нормализация — часть парсинга и находится в зоне ответственности I/O. При этом объекты-значения, согласно «Чистой архитектуре», являются частью предметной области. Поэтому нормализация как часть реализации объекта-значения является спорной, необязательной и зависит от конкретной ситуации.

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

Заключение

Объект-значение — это обёртка над неизменяемыми данными, определяемая исключительно своими данными. Сущность, помимо данных, имеет идентификатор. И объекты-значения, и сущности могут содержать бизнес-логику.

«Одержимость примитивами» в коде — это почти так же плохо, как пользовательская форма с текстовыми полями для всего или база данных, сплошь заполненная строками: теряется смысл и допускается ввод некорректных данных. Объекты-значения привносят семантику в API и сущности. В контексте приложения, я рассматриваю объекты-значения на одном уровне с примитивными типами. В некоторых случаях они помогают компилятору (или интерпретатору, — прим. пер.) отловить ошибки на ранней стадии.

Учитывая небольшие затраты и большую пользу, я рекомендую как можно раньше выделять и создавать объекты-значения на проекте. Побуждающим к действию сигналом будет момент, когда вы начнете жонглировать литералами (парсить, разделять, валидировать, конвертировать и так далее).

Объекты-значения имеют ценность и смысл в большинстве языков программирования, объектно-ориентированных и нет. Самое время погуглить на тему «объекты-значения в [мой язык программирования]».

Оригинал статьи