Nakedobjects

Давно собирался внимательно посмотреть на Голые объекты и хотел на их основе (+ AOP + BRMS) сделать демо-приложение предметной области описанной в документе определения бизнес-правил. И вот нашел немного времени ...

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

Также нужно обратить внимание, что большое количество труда приходится именно на перемещение объектов между слоями. Есть объект - его нужно хранить в БД, загружать в модель домена и отображать для работы пользователя в UI. Все это конечно слишком общие слова, но если посмотреть внимательно на приложения ориентированные на данные - именно так и есть. Даже если внутри не объекты а наборы данных, которые отображаются стандартными сетками... Как-то я пытался построить наконец универсальный контур для построения приложений ориентированных на данные, да как обычно переключился на другие, более интересные дела. В общем идея голых объектов во многом похожа на то прошлое начинание, только вертится она вокруг объектов а не вокруг наборов данных.

Практически в любом приложении центральная часть - это предметная область, или домен. Есть технологии, которые облегчают отражение модели предметной области на остальные части приложения. Например ORM решает проблему прозрачного хранения объектов предметной области в долговременной памяти. (Можно долго говорить о достоинствах и недостатках ORM, но это уже объективная реальность. Инвестиции в моделирование, JDBC и/или ORM) Naked objects применяют тот же подход и к слою интерфейса. При этом используется расширенный набор аннотаций ...

Приложения Naked Objects состоят из двух основных компонентов - объектов предметной области и сервисов. Каждый объект представленный в интерфейсе пользователя должен иметь соответствующий класс java. Не зависимо от типа репозиториев (RDBMS, Hibernate, XML Store) CRUD операции библиотека реализует сама. Другие взаимодействия реализуются сервисами (просто классы с операциями). В общем кого заинтересовало - читайте руководство и смотрите примеры ... В поставке инструмента идут два примера - desktop и web, правда в последней 3.0.2 версии desktop глючит отображение списков.

PS

Создать свое приложение крайне просто. Прошел первую часть руководства и сделал тестовый проект Customer desktop и web, пока без аннотаций. Вообще аннотации не очень радуют, но по другому как придать дополнительную смысловую нагрузку - появляется слой :) Да еще конфигурационные файлы тоже присутствуют. В следующий присест займусь предметной областью аренды ...

О "дикости" интерфейса ... наверное просто нужно привыкнуть. Первое время за 1С тоже парился привыкал к большому количеству - сейчас вроде смирился.

Майские праздники

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

В последнее время что-то тянет на вещи, для работы которых не требуется электричества ...

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

(С) какой то типа шансон года эдак 60-70

Drools Examples

Смотрю примеры Drools в документации - как по мне довольно интересны - решил привести их здесь ...

* Hello World - фокусируется на основных классах и механизмах машины правил, плюс показывает отладку и проверку самого вывода.

* State Example - показывает три различных способа управления последовательностью срабатывания правил и динамическое подключение правил.

* Banking Tutorial - использует правила для подсчета сумм на счетах после серии операций дебета и кредита

* Fibonacci Example - строит с использованием правил ряд фибоначчи

* Golfing Example - показывает пример решения комбинаторной задачи, для которой есть несколько фактов условия и нет очевидных алгоритмов решения:

1. Пары играющих в гольф выстраиваются в линию слева направо
2. Каждый игрок носит брюки разного цвета; один игрок одет в красные брюки
3. Игрок сразу справа от Фреда одет в голубые штаны
4. Джо стоит вторым
5. Боб одет в штаны в клетку
6. Том не стоит в первой или четвертой позиции, и не одет в ужасные оранжевые штаны

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

На тему примера вспоминается школьная игра "Быки-Коровы". Один игрок загадывает четырех-значное число с цифрами от 1 до 9, где цифры не могут повторяться - другой должен отгадать число за наименьшее количество ходов. Разгадывающий называет число предположение, загадывающий должен сказать сколько там "Коров" и "Быков". "Быки" - цифры которые есть в загаданном числе и стоят на своем месте, Коровы тоже есть в числе, но стоят в отличных позициях. Где-то в книжке, уже утерянной был алгоритм работы через множества и возможно с некоторыми ограничениями по исходным цифрам. И он угадывал любое число максимально за 5 хоодов. Интересно попробовать повторить в Drools ...

* Trouble Ticket - пример работы с приоритетами правил. Пример построен вокруг технической1 поддержки - есть клиенты и статус подписки (silver, gold, platinum). В зависимости от статуса используются разные варианты движения запроса и скорость реакции на запрос. Сначала обрабатываются запросы platinum, затем gold и потом уже silver.

* Pricing Rule Decision Table Example - демонстрирует использование таблицы решений (формат XLS) для вычисления розничной стоимости страхового полиса. Правила используются для расчета базовой цены и дополнительных скидок для водителей автомобилей на основе возраста, истории отношений и т.д.

* Shopping Example - пример корзины покупателя, где в зависимости от суммы покупок назначаются скидки

* Pet Store Example - показывает интеграцию Правил с GUI, MVEL диалект, вызов функций Java из набора правил. Много букоф в логике - смысл смотрите самостоятельно.

* Honest Politician Example - пример о жизни и смерти демократии на основе существования честных политиков :)

* Sudoku Example - уже навороченный пример с большим пространством решений и интеграцией со Swing UI по известной головоломке Sudoku.

Игровое поле представляет собой квадрат размером 9x9, разделенный на меньшие квадраты со стороной в 3 клетки. В некоторых из них в начале игры стоят числа (от 1 до 9). В зависимости от того, сколько клеток уже заполнены, конкретную судоку можно отнести к легким или сложным.

У судоку есть всего одно правило. Необходимо заполнить свободные клетки цифрами от 1 до 9 так, чтобы в каждой строке, в каждом столбце и в каждом малом квадрате 3x3 каждая цифра встречалась бы только один раз.

* Number Guess - демонстрация простой игры Угадай число. Демонстрирует использование диаграммы и редакторов потоков правил (Rule Flow). Интересная вещь, требующая более внимательного изучения.

* Miss Manners and Benchmarking - пример демонстрирует размещение гостей за столом, так чтобы они сидели парами мальчик + девочка и у них были общие темы для разговора. ??? приводятся известные алгоритмы измерения производительности продукционных систем; стратегии разрешения конфликтов, особенности работы CLIPS ... вопрос требует внимательного изучения ???

* Conways Game Of Life Example - демонстрация игры Конвея "Жизнь" с использованием RuleFlow. Долго втыкал в игру ...

Место действия этой игры — «вселенная» — это размеченная на клетки поверхность, безграничная, ограниченная, или замкнутая. Каждая клетка на этой поверхности может находиться в двух состояниях: быть живой или быть мертвой. Клетка имеет восемь соседей. Распределение живых клеток в начале игры называется первым поколением. Каждое следующее поколение рассчитывается на основе предыдущего по таким правилам:

• пустая (мёртвая) клетка ровно с тремя живыми клетками-соседями оживает;
• если у живой клетки есть две или три живые соседки, то эта клетка продолжает жить; в противном случае (если соседок меньше двух или больше трёх) клетка умирает (от «одиночества» или от «перенаселённости»).

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

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

* Insurance Company Risk Factor and Policy price (using BRMS) - демонстрирует использование BRMS для создания и запуска правил.