Должны ли Value Object быть Final?

Question

[Dos]

Привет. Есть Value Objects разного типа. Замечал, что кто-то эти VO делает финальными. Соотвественно теряется возможность их наследования и изменения.

У меня есть VO: Status и Role. Их я Использую с Doctrine. Мне не достаточно передавать просто названия статуса. Хочу использовать расширенно и поместить проверку в конструктор на определенные Типы статусов: активный, неактивный, опубликованный.

Если статус не является одним из них - выбрасываем исключение. Так же было бы удобно в самом статусе создавать объект через методы фабрики: Status::active(), Status::publish().

В стандартном VO такого нет. Поэтому, хочу наследоваться, добавить свой функционал и использовать его.

Но сейчас пошли некоторые сомнения. Статус используется много где, как и роли. Так же он является не изменяемым. Тогда логично считать, что это VO. Но тут получается, что иногда его нужно наследовать и использовать со своими дополнительными проверками.

Возникло два вопроса:
1. Нужно ли создавать финальные классы для VO?
2. Является ли статус и роль VO?

Answer 1

[Максим Федоров]

Если статус не является одним из них - выбрасываем исключение. Так же было бы удобно в самом статусе создавать объект через методы фабрики: Status::active(), Status::publish().

Такой тип с перечислением необходимых значений называетсяEnum, Enum можно считать VO
Абстрактный функционал вашего псевдотипа, понятное дело, не будет финальным, но конкретные VO конечно делайте final и будет все хорошо.

Единственное сложные VO трудновато будет тестировать с final модификатором, вам поможет например uopz расширение.

Для статусов/ролей/id делать VO — круто и хорошо, делать final — тоже

В догонку статья от Ocramius: When to declare classes final

Comments

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

или библиотеки типа такой https://github.com/lisachenko/z-engine

Учитывая её лицензию, я бы не советовал.

[Dos]

Спасибо за ответ) За библиотеку тоже спасибо. Есть несколько уточнений, которые так и не понял:
1. То есть все VO лучше делать финальными, верно?
2. Статус может быть VO, но если мы хотим иметь дополнительную функциональность - мы создаём другой VO Status, верно?

Конкретно ENUM использовать не хочу. Так как в одной сущности ENUM может быть два и более. Например, роль и статус. И уже есть вероятность поменять местами эти данные и в статус будет попадать роль. Поэтому, от этого хочу уйти своим типом, но с проверкой.

[Максим Федоров]

pro-dev,

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

Как это?

Вот класс:

final class Status extends Enum
{

}

Вот метод

changeStatus(Status $status): void
{
     $this->status = $status->getValue();
}

Как сюда роль попадет?

[Максим Федоров]

2. Статус может быть VO, но если мы хотим иметь дополнительную функциональность - мы создаём другой VO Status, верно?

Мне стало казаться, что под VO вы понимаете какой-то класс?
Это не конкретный класс, это просто собирательное именование некого вида классов

[Dos]

Максим Федоров, в таком случае роль никак не попадает. Грубый пример на User. При создании User через конструктор мы добавляем и роль и статус. Поэтому в чистом виде ENUM использовать не хорошо, но если наследовать, то уже лучше. Однако я создам финальный класс Status наследованный от ENUM. Он будет общий. Но если я или кто-то захочет создать статус, в котором есть фабричные методы ::active() и ::publish(), то уже проблема. В таком случае мне надо создавать свой Status. Верно?) или я что-то не понимаю?