The problem is that you almost never create an object fully formed with all the behaviour it is ever going to need, rather you build it up over time.
...
So, early on you don't feel like your objects' state machine behaviour is complex enough to warrant a "full-blown" state machine (YAGNI and all that jazz), but later on – when it IS complex enough – you feel like you've invested too much time/effort to replace it with something that has equivalent functionality
Завершилось имхо наивным тезисом:
We seem to shy away from state machines due to misunderstanding of their complexity and/or an inability to quantify the benefits
Формальные бенефиты канонишной стейт машины имхо всем понятны. Вот только... не встречалось мне еще задач под канонишные стейт машины. Вот моя типичная задача — есть заявка, у нее 3 последовательных этапа согласования. Этапа 3 но состояние у заявки одно — "заявка на согласовании". Согласование может закончится тремя вариантами — заявка согласована, заявка не согласована, согласование просрочено. Это уже статусы заявки, которые она получает после этапа "согласование". Далее есть автоматические согласования (если выполнен ряд условий) и "сгруппированные согласования" — (параллельные) тоже со своими правилами — или за группу согласует первый или должна согласовать вся группа. Автоматическое согласование легко может сработать несколько раз после "ручного согласования" и завершить согласование группы, согласование этапа и согласования заявки. А и в каких-то случаях вообще все согласование может быть пройдено и завершено на автомате сразу после старта согласования.
Казалось бы напрашивается стейт машина. Но границы сущностей размыты... Состояние заявки вроде бы и связано с состоянием процесса согласования, но детали процесса согласования могут быть очень сложными и серьезно меняться при этом, никак не отражаясь на логике связанной с самой заявкой. Да и самой заявке стейт машина бывает не больно то нужна, если у заявки простая система состояний.
В подобной ситуации основной смысл стейт машины — декларативность, как-то имхо пропадает. Или надо под каким-то другим "углом" на эту проблему смотреть?
Здравствуйте, IQuerist, Вы писали:
IQ>В подобной ситуации основной смысл стейт машины — декларативность, как-то имхо пропадает. Или надо под каким-то другим "углом" на эту проблему смотреть?
У тебя простенькая задача которую можно разрулить 2-мя флажками. Попробуй реализовать какой-нибудь мало-мальски серьёзный телеком протокол, например SIP где состояний может быть 20+ и без стейт-машины ты не обойдёшься, особенно деклартивной и чтобы компайл тайм проверка была хоть какая-нибудь.
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, IQuerist, Вы писали:
IQ>>В подобной ситуации основной смысл стейт машины — декларативность, как-то имхо пропадает. Или надо под каким-то другим "углом" на эту проблему смотреть? K>У тебя простенькая задача которую можно разрулить 2-мя флажками.
Очевидно не сталкивались вы с процессами согласования
K>Попробуй реализовать какой-нибудь мало-мальски серьёзный телеком протокол, например SIP где состояний может быть 20+ и без стейт-машины ты не обойдёшься, особенно деклартивной и чтобы компайл тайм проверка была хоть какая-нибудь.
Ну вот были у меня заявки где over 15 состояний, простых как тапок, с двумя — тремя ветвлениями, я даже и не думал заводить под них стейт машину. Так что количество не показатель.
Здравствуйте, IQuerist, Вы писали:
IQ>Казалось бы напрашивается стейт машина. Но границы сущностей размыты...
Кэп: а вот нефиг смешивать "состояние заявки" и "состояние бизнес-операции, в которой участвует заявка". Разнесите, пропишите инварианты для каждого состояния, пропишите правила перехода, собственно всё.
По сабжу... а по сабжу уже за меня ответили, подпишусь:
mkamoski • 4 years ago
Never use them? What? A state-machine is as simple as a non-nullable foreign key. It is an "abstract idea", a design principle. Implementation is secondary. You have some nice thoughts and evangelization here in your article, but you are mistaken that "developers never use state machines". Heck a boolean variable is a state machine-- holds exactly one value from a finite set of values. Etc. Just saying. Thanks.
Здравствуйте, IQuerist, Вы писали:
IQ>Здравствуйте, Kernan, Вы писали:
K>>Здравствуйте, IQuerist, Вы писали:
IQ>>>В подобной ситуации основной смысл стейт машины — декларативность, как-то имхо пропадает. Или надо под каким-то другим "углом" на эту проблему смотреть? K>>У тебя простенькая задача которую можно разрулить 2-мя флажками.
IQ>Очевидно не сталкивались вы с процессами согласования
Возможно я не очень сильно вчитывался в твою специфику. Бегло взглянув на предыдущее сообщение, мне показалось, что у тебя должно быть стейтов от 3-х и 3-5 событий. IQ>Ну вот были у меня заявки где over 15 состояний, простых как тапок, с двумя — тремя ветвлениями, я даже и не думал заводить под них стейт машину. Так что количество не показатель.
Я перечитал твой пост ещё раз, у меня складывается впечатление что ты не совсем понимаешь как строить стейт машины исходя из своих требований и какие проблемы они решают.
Ну и как бы посыл статьи "мы осознаём, что надо было использовать стейт-машины слишком поздно и не делаем это с самомго начала т.к. это слишком сложно", очевидно, что вся сложность в голове, лени и банальном отсутствии инженерной воли использовать на старте довольно массивный инструмент.
[занудамод]
Если сомтреть с т.з. императивного програмимрования, то вся наша программа это не что иное как банальная стейт-машина с множеством переходов.
[\занудамод]
Здравствуйте, Kernan, Вы писали:
K>Я перечитал твой пост ещё раз, у меня складывается впечатление что ты не совсем понимаешь как строить стейт машины исходя из своих требований и какие проблемы они решают. K>Ну и как бы посыл статьи "мы осознаём, что надо было использовать стейт-машины слишком поздно и не делаем это с самомго начала т.к. это слишком сложно", очевидно, что вся сложность в голове, лени и банальном отсутствии инженерной воли использовать на старте довольно массивный инструмент.
Посыл имхо в том, что очевидность необходимости использования стейт-машины в современных проектах появляется не на ранних этапах проекта. Имхо лень тут не при чем.
K>[занудамод] K>Если сомтреть с т.з. императивного програмимрования, то вся наша программа это не что иное как банальная стейт-машина с множеством переходов. K>[\занудамод]
Да, но проблема в том, что в современных (итеративных) проектах все переходы становятся известными ближе к середине проекта.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, IQuerist, Вы писали:
IQ>>Казалось бы напрашивается стейт машина. Но границы сущностей размыты... S>Кэп: а вот нефиг смешивать "состояние заявки" и "состояние бизнес-операции, в которой участвует заявка". Разнесите, пропишите инварианты для каждого состояния, пропишите правила перехода, собственно всё.
Да вот проблема итерационных проектов в том, что еще вчера не было никакого особенного "состояние бизнес-операции", вернее оно конечно было но было пустым или практически пустым, а сегодня аналитики переговорили с заказчиками и вчерашнее простенькое согласование превращается в полноценный и ЧСХ сложный бизнес процесс... Хуже того, всегда хочется обойтись "малой кровью" (т.к. сроки всегда поджимают) и обойтись простым решением, что конечно не всегда получается.
Здравствуйте, IQuerist, Вы писали:
IQ>а сегодня аналитики переговорили с заказчиками и вчерашнее простенькое согласование превращается в полноценный и ЧСХ сложный бизнес процесс...
Ну тут как... или находим биз-аналитика (чтоб ещё найти, проблема та ещё), или пытаемся сами за него работать, или постоянно наступаем на грабли "да ктож знал-то?!!" Третий вариант самый увлекательный, примерно как с свободным падением: вся проблема в последних сантиметрах
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, IQuerist, Вы писали:
IQ>>а сегодня аналитики переговорили с заказчиками и вчерашнее простенькое согласование превращается в полноценный и ЧСХ сложный бизнес процесс...
S>Ну тут как... или находим биз-аналитика (чтоб ещё найти, проблема та ещё), или пытаемся сами за него работать, или постоянно наступаем на грабли "да ктож знал-то?!!" Третий вариант самый увлекательный, примерно как с свободным падением: вся проблема в последних сантиметрах
Не могу в моем случае (внутрикорп. системы) ругать ни аналитиков, ни заказчиков. На всех давят, от всех требуют соблюдения новых бизнес процессов с минимальными бюджетами.
Я еще на первой подобной работе начал принимать такую ситуацию как данность. А уж теперь когда 10 лет "в теме" иное положение дел меня просто изумляет ))) Впрочем в такой ситуации имхо есть даже серьезный плюс — г...код и over-engeniring в 99% случаев тебе же создадут проблемы в самом ближайшем будущем. Так что приходится все время очень внимательно следить за тем, что делаешь.
Здравствуйте, IQuerist, Вы писали:
IQ>Не могу в моем случае (внутрикорп. системы) ругать ни аналитиков, ни заказчиков. На всех давят, от всех требуют соблюдения новых бизнес процессов с минимальными бюджетами.
Не, какой ругать? Наоборот холить и лелеять надо. Хороший аналитик и хороший QA в команде — это подарок подарков, главное общение наладить.
В смысле, кроме "кровь из носу надо" надо узнавать ещё и про "тут заказчики такую фигню намереваются попросить". Не для реализации, понятное дело, а чтобы правильно приоритеты расставлять. Не всегда оно получается, но хотя бы пытаться точно надо.
Здравствуйте, IQuerist, Вы писали:
IQ>В подобной ситуации основной смысл стейт машины — декларативность, как-то имхо пропадает. Или надо под каким-то другим "углом" на эту проблему смотреть?
Здравствуйте, IQuerist, Вы писали:
IQ>Да, но проблема в том, что в современных (итеративных) проектах все переходы становятся известными ближе к середине проекта.
Это не так. Если в проекте есть опытный инженер, то ему будет очевидно куда будет развиваться проект, но опытные инженеры обычно не имеют власти или они должны прогибаться под менеджера. Более того существует целый класс типовых задач (протоколы, ага) которые уже лет 30-ть эффективно решаются с использованием стейт-машин.
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, IQuerist, Вы писали:
IQ>>Да, но проблема в том, что в современных (итеративных) проектах все переходы становятся известными ближе к середине проекта. K>Это не так. Если в проекте есть опытный инженер, то ему будет очевидно куда будет развиваться проект, но опытные инженеры обычно не имеют власти или они должны прогибаться под менеджера.
Книжные какие-то условия... В реальной жизни имхо идет поток проектов и если даже опытному инженеру понятно куда будет развиваться проект, то будет ли это развитие оплачено заказчиками для него обстоятельство абсолютно неизвестное, а для планирования усилий ключевое.
>>>Более того существует целый класс типовых задач (протоколы, ага) которые уже лет 30-ть эффективно решаются с использованием стейт-машин.
Здравствуйте, Kernan, Вы писали:
IQ>>Да, но проблема в том, что в современных (итеративных) проектах все переходы становятся известными ближе к середине проекта. K>Это не так. Если в проекте есть опытный инженер, то ему будет очевидно куда будет развиваться проект, но опытные инженеры обычно не имеют власти или они должны прогибаться под менеджера. Более того существует целый класс типовых задач (протоколы, ага) которые уже лет 30-ть эффективно решаются с использованием стейт-машин.
Это ж элементарно, захардкоженный монолит с машиной состояний в одной точке. Вот бы с behaviour tree на практике поладить, мне кажется можно хочу с ним сделать нечто вроде dependency injection: склеить протокол из кубиков.
Здравствуйте, IQuerist, Вы писали:
IQ>Ну вот были у меня заявки где over 15 состояний, простых как тапок, с двумя — тремя ветвлениями, я даже и не думал заводить под них стейт машину. IQ>Да и самой заявке стейт машина бывает не больно то нужна, если у заявки простая система состояний.
Состояния и переходы, кода не вижу, но судя по описанию это и есть машина состояний. Её можно создать по-разному, но сути это не меняет, условное ли ветвление, таблица переходов или что-то ещё. Важнее признаки, которыми она наделяется, например, детерминированная или недетерминированная. Конечно всё это не значит, что конкретная реализация не важна, ещё как важна. Другое дело, что даже если машина состояний кажется простой, то от этого она не перестаёт быть машиной состояний.
