Сложный алгоритм - Как хранить правила отдельно от обработки кода?

Question

Я работаю над проектом, который проведет сложный анализ некоторых пользовательских данных. Там будет 3 части кода:

1) Вводимые пользователем данные, например ключевые слова

2) Правила, например, если ключевое слово 1 повторяется 3 раза в ключевом слове 5, сделать это и т. Д.

3) И сам анализ, который выполняет правила и обрабатывает пользовательский ввод и генерирует выходные данные, необходимые на основе обработки.

Естественно, это приведет к большому количеству спагетти-кода и множеству операторов if в коде обработки. Я хочу этого избежать и хранить правила (то есть операторы if) отдельно от кода, который проходит через пользовательский ввод и генерирует вывод.

Как я могу это сделать, т. Е. Как лучше?

Answer 1

Если у вас достаточно правил, которые вы хотите вывести на экстернализацию, вы можете попробовать использовать механизмы бизнес-правил, например Drools в Java.

Механизм бизнес-правил - это программная система, которая выполняет одно или несколько бизнес-правил в рабочей среде во время выполнения. Правила могут исходить из правового регулирования («Сотрудник может быть уволен по любой причине или без причины, но не по незаконной причине»), политики компании («Все клиенты, которые тратят более 100 долларов за один раз, получат скидку 10%») ) или другие источники. ( Википедия )

Это может быть немного накладно в зависимости от того, что вы пытаетесь сделать. В моей компании мы используем такие инструменты для анализа качества.

Answer 2

Ну, я сомневаюсь, что необходимо иметь правильные утверждения, если полиморфизм применен правильно.

На самом деле, вам нужна правильная модель домена для ваших правил. Это каким-то образом идет в направлении шаблона команды, в зависимости от сложности вашего кода, возможно, в сочетании с шаблоном конечного автомата.

Если у вас есть модель, определение правил - это создание их правильных экземпляров.

Это можно сделать с помощью определения xml, которое анализируется и преобразуется в вашу модель. Но новый современный и еще более причудливый способ будет использовать DSL. Если вы программируете на Java и обладаете определенной свободой в отношении своих библиотек, это будет правильным вариантом для встроенных DSL с Groovy . По сути, вам нужен Builder, который создает вашу модель, вот и все.

Answer 3

Сохраните его в XML. Легко анализировать и обновлять.

Я разработал генератор кода, которым можно управлять из XML-файла. Для каждой команды у меня была запись в XML. Я обрабатывал узел для генерации кода операции для этой команды. Сам узел содержит действия, которые мне нужно сделать для получения кода операции. Для некоторых команд мне пришлось искать в базе данных, все те вещи, которые я положил в этот XML-файл.

Answer 4

Взгляните на правило двигателей !

Подход Ларса также может быть спорным.

Answer 5

Если это просто обнаружение ключевых слов, конечный автомат или подобное. Если он делает больше, то другие системы сопоставления с образцом, такие как механизмы правил.

Answer 6

Добавление встроенного скриптового языка в ваше приложение может помочь. Затем правила будут выражаться в сценариях, выполняемых приложениями при обработке.

Идея состоит в том, что скрипты легко изменить и они содержат высокоуровневую логику, которая будет подробно выполняться вашим приложением.

Для этого доступно множество языков сценариев: lua, Python, Falcon, белка, angelscript и т. Д.

Answer 7

Вы всегда можете реализовать фабрику, которая будет создавать определенные стратегии в соответствии с переданными параметрами. И тогда вы будете использовать эти стратегии в своем коде без каких-либо if.