СП
а что будет в основной таблице?
Size: a a a
2021 July 20
RL
В паттернк состояние есть сам стейт и контекст. Взаимодействие клиентского кода осуществляется через контекст(сам агрегат)
HH
Айдишники проджекта и проджектинфы
СП
то есть в агрегате будут методы для взатмодействия со всеми стейтами? Тогда нет смысла в стейты выносить
СП
а смысл тогда этой таблицы?
RL
Стейты нужны, чтобы if-ов не было в методах.
СП
так они все равно будут, так как нужна проверка, что у нас нужный статус
RL
В одном месте, когда стейт внедрять в агрегат.
HH
Ну это сейчас у тебя там ничего кроме ProjectInfo нет
RL
А там полиморфизм в деле, и if’ы не нужны
СП
в каждом методе нажо проверять же, чтобы понимать к какому стейту обращаться
СП
не пойму как это решит проблему сохранения агрегатов( Может есть пример?
RL
У агрегата будет свойство _state. При изменении одного стейта на другой будет подменяться объект стейта на иной. Правила перехода от стейта к стейту можно внутри самих стейтов инкапсулировать.
СП
да, но чтобы обращаться к стейтам мне нужно все методы со всех стейтов продублировать в агрегат, так как по другому я не смогу их вызывать
SP
Надо выписать все этапы жизненного цикла, общие вещи можно вообще в свои агрегаты вынести. Так проверки вида "если статус такой-то" заменяются на "если такой агрегат вообще есть". Переходы статусов - одни агрегаты поражают другие
RL
Часто методы новые будут появляться? Если да, то можно паттерн Визитор.
HH
Что за проблема? Я не понимаю)
СП
что делать со старым агрегатом, когда он новый породил?