Есть объект Заказ.
У него может быть порядка 30 статусов.
Есть админка где админ может заказ с любого статуса перекинуть в любой статус.
То есть если всё расписывать по каждой комбинации то получается дофига ифов и много дублирования получится.
Наверняка есть проверенные шаблоны для такого? Какие?
Сперва вроде понятно было. Но тут все рассыпалось: S>То есть если всё расписывать по каждой комбинации то получается дофига ифов и много дублирования получится.
Здравствуйте, snaphold, Вы писали:
S>Наверняка есть проверенные шаблоны для такого? Какие?
Если из одного статуса возможен переход в строго ограниченное количество статусов и вопрос только в этом, то можно ассоциативные массивы использовать (std::map<enum, enum>), задав пары ключ->значение для каждого из возможный изменений статуса заказа или ключ->множество статусов (std::map<enum, std::set<enum>>)
Здравствуйте, Maniacal, Вы писали:
M>Если из одного статуса возможен переход в строго ограниченное количество статусов и вопрос только в этом, то можно ассоциативные массивы использовать (std::map<enum, enum>), задав пары ключ->значение для каждого из возможный изменений статуса заказа или ключ->множество статусов (std::map<enum, std::set<enum>>)
Нафига там map? Таблица почти наверняка статическая, для статических таблиц очень хорошо подходит старый добрый массив.
Здравствуйте, Pzz, Вы писали:
Pzz>Нафига там map? Таблица почти наверняка статическая, для статических таблиц очень хорошо подходит старый добрый массив.
Только если статусы это zero-based набор перечисляемого типа, где номера идут подряд.
Здравствуйте, Maniacal, Вы писали:
Pzz>>Нафига там map? Таблица почти наверняка статическая, для статических таблиц очень хорошо подходит старый добрый массив.
M>Только если статусы это zero-based набор перечисляемого типа, где номера идут подряд.
Обычтно эти статусы — внутреннее дело программы, и их можно хранить в удобном виде. Даже если они хранятся где-то в базе, можно делать преобразование при сохранении/загрузке данных.
Здравствуйте, snaphold, Вы писали:
S>Есть админка где админ может заказ с любого статуса перекинуть в любой статус.
Вне зависимости от реализации, это будет источником постоянной головной боли. Модифицируйте бизнес процесс, чтобы такого бардака не было. А потом у вас нарисуются красивые state machine, и валом фреймворков чтобы их заимплементить, все как полагается.
Здравствуйте, snaphold, Вы писали:
S>Есть объект Заказ. S>У него может быть порядка 30 статусов. S>Есть админка где админ может заказ с любого статуса перекинуть в любой статус. S>То есть если всё расписывать по каждой комбинации то получается дофига ифов и много дублирования получится.
S>Наверняка есть проверенные шаблоны для такого? Какие?
Это вроде как workflow называется. Но что-то у тебя не то в подходе. Админ не должен менять статусы как пожелает, а применяет доступные бизнес-операции, что влечёт изменение статуса. Например, админ не просто напрямую меняет значение статуса из "размещён" в "оплачен", а проводит операцию оплаты заказа, вводя данные кредитки и после успешной оплаты статус меняется сам. Т.е. статус это поле, вычисляемое на основании применёных к заказу операций.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Если хочешь захардкодить, фигачь кучу свитчей, в одном месте, это то, что надо. А в идеале делай в базе табличку с возможными переходами, но если увлечёшься, напишешь Jira.
Здравствуйте, snaphold, Вы писали:
S>Есть объект Заказ.
Мы не знаем, корректная ли это абстракция. S>У него может быть порядка 30 статусов.
Скорее всего, некорректная. S>Есть админка где админ может заказ с любого статуса перекинуть в любой статус.
И, конечно же, никакого аудита подобных действий. Проект обречен на успех и точно переживёт три мажорных версии. S>То есть если всё расписывать по каждой комбинации то получается дофига ифов и много дублирования получится.
S>Наверняка есть проверенные шаблоны для такого? Какие?
Я рекомендую ООП и DDD. (Тут вылезают умники, которые пишут хранимые процедуры для баз данных, но не на SQL, а прямо в компилируемом коде через призму какой-нибудь ORM, и заявляют, что ООП не работает и встречается только в учебниках, но я не рекомендую их слушать.)
Здравствуйте, snaphold, Вы писали:
S>Есть админка где админ может заказ с любого статуса перекинуть в любой статус. S>То есть если всё расписывать по каждой комбинации то получается дофига ифов и много дублирования получится.
Здравствуйте, snaphold, Вы писали:
S>Есть объект Заказ. S>У него может быть порядка 30 статусов. S>Есть админка где админ может заказ с любого статуса перекинуть в любой статус. S>То есть если всё расписывать по каждой комбинации то получается дофига ифов и много дублирования получится.
S>Наверняка есть проверенные шаблоны для такого? Какие?
Такого варианта еще не было: если можно реорганизовать состояния в виде состояний и подсостояний, то для реализации состояний используем паттерн state из gof, а для подсостояний — state machine.
но вот момент какой непонятен.
вот если берем пример из ссылки
Есть таблица переходов у меня есть переход из Paused в Exit.
Соответственно как это будет выглядеть? StateMAchine я так понял хорош когда надо перейти в соседнее состояние, а когда надо перейти через несколько состояний как быть?
Здравствуйте, Буравчик, Вы писали:
Б>Здравствуйте, snaphold, Вы писали:
S>>Есть админка где админ может заказ с любого статуса перекинуть в любой статус. S>>То есть если всё расписывать по каждой комбинации то получается дофига ифов и много дублирования получится.
Б>Что расписывать? И дублирование чего?
Объект из состояния 1 может перейти в 20 состояний
Объект из состояния 2 может перейти в 20 состояний
...
Объект из состояния 20 может перейти в 20 состояний
при переходе из состояния 20 в состояние 1 и при переходе из состояния 19 в состояние 1 будет одинаковая логика, кроме одного метода (20 => 19)
но вот момент какой непонятен.
вот если берем пример из ссылки
Есть таблица переходов у меня есть переход из Paused в Exit.
Соответственно как это будет выглядеть? StateMAchine я так понял хорош когда надо перейти в соседнее состояние, а когда надо перейти через несколько состояний как быть?
Здравствуйте, Qulac, Вы писали:
Q>Здравствуйте, snaphold, Вы писали:
S>>Есть объект Заказ. S>>У него может быть порядка 30 статусов. S>>Есть админка где админ может заказ с любого статуса перекинуть в любой статус. S>>То есть если всё расписывать по каждой комбинации то получается дофига ифов и много дублирования получится.
S>>Наверняка есть проверенные шаблоны для такого? Какие?
Q>Такого варианта еще не было: если можно реорганизовать состояния в виде состояний и подсостояний, то для реализации состояний используем паттерн state из gof, а для подсостояний — state machine.
но вот момент какой непонятен.
вот если берем пример из ссылки
Есть таблица переходов у меня есть переход из Paused в Exit.
Соответственно как это будет выглядеть? StateMAchine я так понял хорош когда надо перейти в соседнее состояние, а когда надо перейти через несколько состояний как быть?
Возможно Стейт подойдет, но как обернуть?
Здравствуйте, snaphold, Вы писали:
S>Здравствуйте, Qulac, Вы писали:
Q>>Здравствуйте, snaphold, Вы писали:
S>>>Есть объект Заказ. S>>>У него может быть порядка 30 статусов. S>>>Есть админка где админ может заказ с любого статуса перекинуть в любой статус. S>>>То есть если всё расписывать по каждой комбинации то получается дофига ифов и много дублирования получится.
S>>>Наверняка есть проверенные шаблоны для такого? Какие?
Q>>Такого варианта еще не было: если можно реорганизовать состояния в виде состояний и подсостояний, то для реализации состояний используем паттерн state из gof, а для подсостояний — state machine.
S>Нашел реализацию
S>но вот момент какой непонятен. S>вот если берем пример из ссылки S>Есть таблица переходов у меня есть переход из Paused в Exit. S>Соответственно как это будет выглядеть? StateMAchine я так понял хорош когда надо перейти в соседнее состояние, а когда надо перейти через несколько состояний как быть? S>Возможно Стейт подойдет, но как обернуть?
Не понял вопроса. Представьте себе табличку, где по горизонтали — входные воздействия, по вертикали — текущее состояние, а в клетках — новое состояние. Оформить это можно по разному, в т.ч. привлекая ООП.В общем всё определяется парой: текущее состояние — входное воздействие, в приведенном примере это класс StateTransition, для каждой такой пары мы определяем новое состояние и при необходимости переходим. Т.е. переходить мы можем как нам вздумается.
