Как теоретически работает система правил, подобная той, что используется в Outlook Express? Как это можно сделать?

Question

Мне интересно об этом:

В Microsoft Outlook Express (или Outlook, не помню, я пользователь Mac), у них есть что-то действительно классное. Общие правила:

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

Эти правила выглядели примерно так:

"Если в почтовом ящике есть тема, содержащая 'foo' или 'bar', или 'foobar', удалите ее"

Мне нужно написать нечто похожее для мощной системы проверки формы. Разработчик должен просто иметь возможность создавать такие правила:

rule: [password_1] is_not_equal_with [password_2]
consequence: show_error '2921'

rule: [firstName] has_less_characters_than '2'
consequence: show_error '1211'

rule: [age] is_numeric, is_smaller_than '13', is_greater_than '130'
consequence: show_error '1522'

rule: [gender] is_equal_with 'female'
consequence: show_group [female_questions]

rule: [termsAndConditionsAccepted] is_not_checked
consequence: show_error '482'

rule: [age] is_less_than 21
consequence: hide_group [income_questions]

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

В приведенном выше примере все в квадратных скобках является именем элемента формы html. Все в апострофе '' является жестко закодированным значением для сравнения.

Определенные правила переведены в код PHP и код JavaScript для выполнения проверки на стороне клиента и на сервере.

Функции, на которые он должен быть способен:

• Условные правила: что-то A зависит от чего-то B
• Сравнение значений: для целых чисел, чисел с плавающей точкой, строк
• Включите также некоторую логику управления формой, как в примере «[пол] is_equal_with 'female» ".

Как это могло быть сделано? Какие сущности я должен рассмотреть с научной точки зрения?

Я думаю, что теоретическая концепция этого не зависит от платформы. Хотя я буду реализовывать это в PHP и JavaScript, нет причин, по которым разработчик C ++ не должен отвечать ;-) (Я парень из Objective-C, кстати)

Answer 1

Возможно, вы захотите проверить некоторые движки правил с открытым исходным кодом; или даже платный за один.

Примеры включают
Платите за это:
InRule , Модуль бизнес-правил , Модуль бизнес-правил ASA * ​​1010 *

Opensource:
OpenRules , Слюни

Есть намного больше. Включая некоторые встроенные в Java (API Java Rule Engine (JSR94)), и .Net (Механизм правил Windows Workflow Foundation).

Хотя не уверен насчет прямого PHP.

В качестве примечания я использовал пару движков, таких как Правила Хейли (до того, как они были куплены Oracle) для управления веб-интерфейсом. Имейте в виду, что скорость выполнения абсолютно необходима. У нас был Haley, обрабатывающий около 2000 правил на загрузку страницы (ипотечное приложение), и он выполнялся менее чем за 40 мс (не опечатка). Мы использовали его, чтобы определить, какие поля были на странице, а также определить, были ли введенные данные согласованными, соответствовали ли они правовым стандартам и даже правильно ли они были введены.

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

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

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

Answer 2

Для небольшого количества правил и сообщений вы можете применить алгоритм грубой силы: возьмите каждое правило и каждое сообщение и сравните, если они подходят. Вы получите сложность O (r m ), где r - количество правил, а m - номер сообщения, не принимая во внимание, что правило может иметь несколько условий.

Для огромного количества правил или сообщений вы можете внедрить сеть Rete (http://en.wikipedia.org/wiki/Rete_algorithm). Это занимает немного памяти, но на практике это происходит намного быстрее. В зависимости от того, как вы разрабатываете свои правила, вы получите различные сложности.

Первый подход прост, и я не думаю, что мне нужно это объяснять. Однако, если вам нужна помощь, дайте мне знать, и я подробно опишу эту идею. Позвольте мне объяснить второй подход:

Прочтите немного об алгоритме Rete, прежде чем идти дальше.

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

Правило1 : ЕСЛИ (message.date равно 24.10.2009) И (message.title содержит "привет"), ТО делать что-то1

Правило2 : ЕСЛИ (message.hasAttachement имеет значение ИСТИНА) И (message.date равно 24.10.2009), ТО делать что-то2

Таким образом, альфа-часть сети будет иметь 3 элемента

• C1: (message.date равно 24.10.2009)
• C2: (message.title содержит "привет")
• C3: (message.hasAttachement TRUE)

В бета-сети у вас будет два узла соединения, которые связывают C1-C2 и C3-C1.

Производственные узлы, завершающие бета-сеть, будут содержать последовательность действий, которые должны быть выполнены, когда сообщение удовлетворяет всем условиям правила (в альфа-части) и всех проверках согласованности (в бета-части).

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

Для получения дополнительной информации о Rete:

• Согласование производства для больших систем обучения / - Роберт Б. Доренбос. (1995)
• Об эффективном внедрении производственных систем / - Чарльз Л. Форги (1979)

Answer 3

Цепочка правил в цепи ответственности .

Answer 4

В объектно-ориентированном дизайне одним из подходов является реализация шаблона команды или, для более сложных задач, шаблона интерпретатора. Обычно вы создаете несколько классов для разных категорий правил и можете составлять их для более сложных сценариев (например, путем создания CompositeRule); все они поддерживают такой интерфейс, как Execute () или Execute (context).

Вы создаете очередь экземпляров правил и вызываете Execute (context) для каждого из них для каждого действующего объекта. Контекст будет содержать экземпляр объекта (сообщение, или форма, или что-то еще), на который вы воздействуете.