Один из способов решения дилеммы проектирования, заключающийся в том, чтобы поддерживать сущность всегда действительной, - это распознавать существование конечного автомата.Сущность не ограничивается тем, чтобы оставаться одним типом в течение всего срока ее службы.Сущность - это уникально идентифицируемая вещь, которая иногда может переходить между типами (метаморфозы).
Хотя в заказе может быть как минимум 1 позиция, в корзине покупок может быть от 0 до n товаров.
Как одно состояние перехода?Ну, вы превращаете сущность в какую-то адресуемую вещь, например, ссылку.После того, как вы сделали объект адресом, вы можете использовать неизменяемые объекты.
Неизменяемый объект - это просто постоянная структура данных, которая после создания не может иметь своего состояния.Скорее вы выполняете функции / методы для него, которые возвращают измененную копию исходного объекта с примененным изменением.Это означает, что вызов любой данной функции может вернуть либо тот же тип (с новыми данными), либо новый тип (например, переход конечного автомата).Имея это в виду, вы могли бы иметь переход сущности где-то вниз по потоку от рабочего процесса, от ShoppingCart
к Order
.
Такого рода вещи могут быть выполнены на любом языке, поддерживающем протоколы (Clojure, Swift, Groovy и т. Д.) Или языки, поддерживающие типы объединения (F #, Elm, Haskell, Reason, OCaml).Использование любого из них позволяет одному и тому же сообщению (например, place
) вести себя по-разному.Функция place
на ShoppingCart
проверяет, есть ли у нее все необходимое для перехода на Order
.
Я не утверждаю, что это окончательное решение вашей проблемы.Я просто излагаю это как способ решения проблем этого разнообразия.