И здравствуй проверка в каждом из этих методов, которую надо не забыть поменять, когда добавилось новое состояние.
И никакого здравствуй. Новое состояние описывает только реакцию объекта, которое fsm в этом состоянии осуществляет. Напоминаю, что стейты наследуются - у нас же ООП и силами полиморфизма определяется поведение fsm в данном стейте
Ну значит, вам придется защищаться от рефлексии, от аспектов, а еще нарисовать не поддающегося никакому когнитивному анализу макаронного монстра в setStatus.
Ничего из перечисленного мне не встречалось. А вместо setStatus(Status newStatus_) вполне уместны условные setError(), setIdle() и подобные. (Это если совсем примитивизировать - а на практике ещё и наборы для enter, exit определённые у классов иерархии state и transit у самой fsm) Уж чего чего, а Его Макаронность, ООП как раз отлично структурирует в отличие от
Мой опыт подсказывает, что если вы думаете, то вам нужен конечный автомат, то скорее всего вам не нужен конечный автомат.
Мой опыт подсказывает обратное - везде где встречается сколь угодно отличная от нуля сложность - конечный автомат или их композиция делает систему прогнозируемой и отлаживаемой
Иначе это просто поле status из базы, которое может поменять как угодно кто угодно.
Хорошо, пусть будет status (правда не пойму причём здесь база). И как кто угодно собирается поменять его значение, если оно private? Инкапсуляцию никто не отменял
Может я чего-то и упустил, но тогда Вы говорите о состоянии заказа а не о самом заказе. ООП как раз исходит из сокрытия состояния.
Order1 = pay(Order)
и в функции pay() мы скопируем всё, начиная с австро-прусской войны, включая состав заказа, плательщика-получателя, менеджеров, которые его ведут и прочие погоды на Марсе, важные для прикладной задачи.
Обычно это делают с помощью конечных автоматов.
fsm и ООП никоим образом не противоречат друг другу, а наоборот, очень гармонично взаимно дополняют. А что с хранением истории заказа?
Потому что новый заказ и оплаченный заказ — это две абсолютно разные сущности
Ага, как и ЧастичноОплаченныйЧастичноСобранныйЧастичноОтгруженныйЧастичноВозвращённыйЧастичноОтменённыйИтпИтд заказ. Статус оплаты - один из атрибутов заказа, коих может быть очень много в реальной системе. Сколько видов сущностей надо завести под все возможные сочетания состояний заказа? Как установить между ними всеми связи?
Так вроде снижение ментальной нагрузки - это как раз плюс. Вон у brainfuck ментальная нагрузка о-го-го какая, но чёт на нём никто особо крупных систем не замечено ))
Можно было бы также обсудить и сам вызов методов через точку, появившийся еще в Smalltalk в 1970-ых годах, откуда он и перекочевал в большинство современных языков.
В Smalltalk никакого вызова метода через точку нет.
Срок исковой давности по наследству на недвижимость или оспариванию положений завещания в России составляет 3 года (статья 196 ГК РФ)
ГК РФ Статья 196. Определяет Общий срок исковой давности. И поэтому фраза
Трехлетние сроки исковой давности для требований наследников закреплены в статье 196 Гражданского кодекса РФ,
Минимум не корректна.
Тема со "свежим наследством" - чисто развод клиентов для повышения важности якобы юридической экспертизы - иначе за что деньги брать. Существует множество иных, более реальных угроз для сделок с недвижимостью, но свежее наследство продаётся лучше доверчивым клиентам.
[..] риск того, что его право собственности в течение 3 лет оспорят другие потенциальные наследники. Суд может аннулировать сделку и передать квартиру другим наследникам, а покупателю придётся взыскивать свои деньги с продавца.
Многократно слышал эту байку про 3 года - наследники определяются в течении 6 месяцев с даты раскрытия наследства. Далее - через восстановление сроков посредством судебной процедуры, которая не имеет ограничений по сроку давности. Откуда взялись 3 года как граница "свежего наследства" - совершенно не понятно.
Я не знаю haskell и поэтому не приведу Вам аналогичный пример. Но да, очевидно можно, если приведённый код делает что-либо осмысленное
И никакого здравствуй. Новое состояние описывает только реакцию объекта, которое fsm в этом состоянии осуществляет.
Напоминаю, что стейты наследуются - у нас же ООП и силами полиморфизма определяется поведение fsm в данном стейте
Ничего из перечисленного мне не встречалось. А вместо setStatus(Status newStatus_) вполне уместны условные setError(), setIdle() и подобные. (Это если совсем примитивизировать - а на практике ещё и наборы для enter, exit определённые у классов иерархии state и transit у самой fsm)
Уж чего чего, а Его Макаронность, ООП как раз отлично структурирует в отличие от
Мой опыт подсказывает обратное - везде где встречается сколь угодно отличная от нуля сложность - конечный автомат или их композиция делает систему прогнозируемой и отлаживаемой
Хорошо, пусть будет status (правда не пойму причём здесь база). И как кто угодно собирается поменять его значение, если оно private? Инкапсуляцию никто не отменял
Реализовывал и реализовываю. Подвоха не заметил. Поясните плз, может я чёго-то упускаю?
Может я чего-то и упустил, но тогда Вы говорите о состоянии заказа а не о самом заказе. ООП как раз исходит из сокрытия состояния.
и в функции pay() мы скопируем всё, начиная с австро-прусской войны, включая состав заказа, плательщика-получателя, менеджеров, которые его ведут и прочие погоды на Марсе, важные для прикладной задачи.
fsm и ООП никоим образом не противоречат друг другу, а наоборот, очень гармонично взаимно дополняют. А что с хранением истории заказа?
Ага, как и ЧастичноОплаченныйЧастичноСобранныйЧастичноОтгруженныйЧастичноВозвращённыйЧастичноОтменённыйИтпИтд заказ.
Статус оплаты - один из атрибутов заказа, коих может быть очень много в реальной системе.
Сколько видов сущностей надо завести под все возможные сочетания состояний заказа? Как установить между ними всеми связи?
Так вроде снижение ментальной нагрузки - это как раз плюс. Вон у brainfuck ментальная нагрузка о-го-го какая, но чёт на нём
никтоособо крупных систем не замечено ))А кто ж тогда живёт в methodDictionary ? ))
В Smalltalk никакого вызова метода через точку нет.
Как это Smalltalk без наследования? Там всё на этом построено!
Могу только посоветовать а
ффвтору ознакомиться с "Серебряной пули нет" БруксаSQL - декларативный
Возможно реплицировать только вектор фильтра Блума для отозванных JWT, а при попадании - ходить в лист. Просто, компактно по данным, расширяемо
relocation list можно реплицировать и в нём точно меньше записей, чем было выпущено токенов. А вот ходить за правами ещё куда-то может быть накладно
Что можно сказать ... новая этика.
Где граница между этим и добровольным мониторингом сетки соседа - вдруг он использует подозрительные протоколы - vpn там всякие или ещё чего.
Диды не одобряют
ГК РФ Статья 196. Определяет Общий срок исковой давности. И поэтому фраза
Минимум не корректна.
Тема со "свежим наследством" - чисто развод клиентов для повышения важности якобы юридической экспертизы - иначе за что деньги брать. Существует множество иных, более реальных угроз для сделок с недвижимостью, но свежее наследство продаётся лучше доверчивым клиентам.
Наверное, произнесу страшную крамолу, но мне предпочтительней читать Си с классами, чем темплейтный хейл.
Многократно слышал эту байку про 3 года - наследники определяются в течении 6 месяцев с даты раскрытия наследства. Далее - через восстановление сроков посредством судебной процедуры, которая не имеет ограничений по сроку давности. Откуда взялись 3 года как граница "свежего наследства" - совершенно не понятно.