Comments 6
Все бы хорошо, но по-моему сравнивать код if-else с таблицей несправедливо как для кода, так и для таблицы. По сути, и то, и другое являются различными вариантами записи дерева решений.
В случае с логикой if-else/switch-case это конкретная программная реализация "в лоб", а таблицы решений - представление в виде набора данных. Первое сохраняет иерархичность (наиболее важные и значимые ветвления идут первыми), второе дает гибкость (создавать/изменять таблицы действительно может кто угодно в любом соответствующем редакторе).
Возможно это вкусовщина (да и опыта в бизнесе у меня нет), но с точки зрения простоты и наглядности деревья мне нравятся больше, чем таблицы решений. Впрочем я признаю, что для чего-то действительно сложного, многовариантного и глубокого таблицы подойдут лучше.
Да, вы правы, оба эти подхода применимы и нельзя сказать, что надо одно выбросить, а другое оставить. Но! Логика if-else известна каждому школьнику, а про таблицы решений надо рассказывать.
И это еще пол-дела. Если от теоретических построений перейти к конкретной реализации в системах BPM, то разница будет гораздо более заметной. Логику if-else в нотации BPMN реализуют посредством эксклюзивных шлюзов и при большом числе параметров диаграмма становится просто нечитаемой. Вот, например:
Тут всего-то пара вопросов про возраст аккаунта и траты, а уже какая-то каша.
Но есть способ лучше! Упаковываем это все в набор бизнес-правил и наша модель начинает выглядеть вот так:
И да, манипулировать правилами гораздо удобнее, чем деревом. То есть в плане поддерживаемости этот вариант лучше.
Вы просто скрыли граф под "decision table". А как таблица будет выглядеть для такого "простого примера"?
В табличке хранить конечно проще, если нет визуализации графа.
Я в математике не силен, за граф не скажу. Вот чатик утверждает, что DMN можно рассматривать как ориентированный ациклический граф (DAG), поскольку решения строятся на основе входных данных и других решений, не образуя циклов. Может врет, кто его знает.
Но зачем бы мне визуализация? В том-то и смысл, чтоб иметь компактное представление И как на графе смоделировать множественные выходы, когда hit policy = Collect?
За книжку спасибо, гляну.
Но у меня такое ощущение, что мы говорим немного о разных вещах. В контексте управления бизнес-процессами таблицы решений это то, что определено в стандарте DMN. Это совершенно конкретный механизм, реализованный в Camunda и Flowable.
Просто это статья немного верхнеуровневая, в ней опущены технические детали. Например, такая штука как Hit policy, которая определяет, как именно движок обрабатывает бизнес-правила из таблицы и что будет на выходе.
Еще интересное наблюдение. Касающееся в том числе циклов. Таблицу решений можно воспринимать, как автомат с одним состоянием.
Введение в таблицы решений: Полное руководство для начинающих