ValueObject — зачем?

Question

[Twitt]

Узнал про ValueObject, и "запах" - Одержимость примитивами. Вот выдержка по причинам появления:

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

Допустим в классе User, будет поле orderBy, я сделал поле, сделал setters, getters, в которых я напрямую указал тайпхинтингом, что setOrderBy(int $orderBy) будет принимать параметром и возвращать целочисленное число, в чем я тут проигрываю по сравнению с тем, что я должен был бы сделать класс OrderBy в котором value бы валидировалось на int в конструкторе? Таких примеров масса, как по мне это именно лишние классы, которые не нужны. Может кто то сможет дать пример, почему именно ValueObject а не то как я описал выше?

Заодно, может подскажете, зачем тогда нужны примитивы если можем сделать ValueObject?

Comments

[ddd329]

ValueObject из мира Domain Driven Design (DDD) вы имеете ввиду?

Answer 1

[Максим Грищенко]

Такой Value Object ВИДИМО создали, чтобы логику например его создания не городить в самих сущностях, например у этого VO может быть свой специфичный конструктор. Также у этого объекта возможны методы направления сортировки, вплоть до самых интересных -- эти знания тоже могут быть лишними для нашей сущности... Много чего может быть, вплоть до того, что нужно смотреть на некие другие данные и строить стратегию сортировки. И чтобы не нарушать SRP -- эту всю логику вынесли в самостоятельный объект, который не является сущность, значит в общепринятых терминах -- это VO.

Такое может быть с чем угодно -- с датами, с метатегами (объект Meta для разных сущностей будет как правило с одной сиггатурой), для Id и даже может быть объект Name (в нем могут быть формирования коротких, длинных, сокращённый и всевозможных других состояний)

Если у вас есть вопрос, замечу -- резонный, то вам такая абстракция просто напросто не нужна в силу простоты этого узла системы. Используйте int, но назовите тогда понятным свойством, например position или priority

Answer 2

[Евгений Ромашкан]

Value Object`ы всегда валидны. Не получится создать VO "дата", например VO DateTimeImmutable и записать в него 35 апреля 2019 года.
Они могут состоять из несколких примитивов, например Point из {x,y} или {x,y,z}
Можно удобненько напихать в него статических конструкторов.
Можно на уровне типов требовать сразу валидную дату.

Comments

[Twitt]

а как же пример с OrderBy? Я видел в проекте одном такой VO. Вот в чем смысл, если мы можем в том же сеттере сразу тайпхинтингом указать int?

[Евгений Ромашкан]

Twitt, Поле orderBy в классе User это тоже запах ))
Как и геттеры с сеттерами, зачастую.

По теме - и как понять что значит аргумент int в orderBy? Что будет если я кину туда число 5? 10? -5? 0?

[Twitt]

Евгений Ромашкан, а как не понять что значит orderBy? Ордер пользователя в списке с пользователями, очевидно как по мне, нет?

[Евгений Ромашкан]

Twitt, Если честно, совсем не очевидно, для меня orderBy это поле по которому нужно сортировать коллекцию )
Вы о каком-то порядковом номере(идентификатор?)?