- Pawson R. Naked Objects // IEEE Software. 2002. № 4 (19). C. 81–83.
- Pawson R., Wade V. Agile Development Using Naked Objects Lecture Notes
in Computer Science / под ред. M. Marchesi, G. Succi, Berlin,
Heidelberg: Springer Berlin Heidelberg, 2003.C. 97–103.
Суть шаблона в том, что у конечного пользователя есть прямой доступ к бизнес-объектам системы, а вся функциональность системы выражается в общедоступных методах этих объектов, таким образом гарантируется полнота поведения объектов.
Похоже, что это отличный способ проектировать системы, основываясь на поведении, а не на характеристиках объектов, см. Object thinking - West, David, т.к. всю функциональность системы придется явно распределить по бизнес-объектам, а значит, их нужно будет выделить в ходе анализа и проектирования. НУ а затем еще и всю требуемую функциональность тоже нужно будет описать явно в терминах бизнес-объектов и их действий.
Возможно, что-то похожее можно реализовать и на Smalltalk, особенно, если взять на вооружение Glamorous Toolkit. Идея прототипирования предметной области на более строго объектно-ориентированном языке.
Авторы утверждают, что такой шаблон может повысить гибкость бизнес-системы в двух смыслах:
- стратегически - система становится более приспособленной к будущим изменениям за счет выраженной инкапсуляции бизнес-функций, что в свою очередь приводит к хорошей изоляции точек внесения изменений в функциональность.
- на уровне операционной деятельности - бизнес-клиент в таком подходе рассматривается больше как “решающий проблемы”, а не как “следующий по шагам процесса”. Этому способствует более выразительный интерфейс (в смысле, что все доступные бизнес-операции явно отражены в интерфейсе).
Для разработчиков также есть два плюса:
- более качественная коммуникация с пользователями (заказчиками) за счет единого языка и возможности формулировать требования в терминах существующих или новых объектов и их поведения.
- быстрый цикл разработки (скорее, правда, прототипирования) за счет того, что фреймворк берет на себя работу по созданию / обновлению UI и обновления слоя данных.
Фаза предварительного исследования предметной области совместно с пользователями позволяет не просто создать прототип UI, но и получить качественную объектную модель. Быстрая обратная связь и формирование Единый язык в разработке ПО. Найденные объекты могут послужить отличным источником бизнес-идей, не предусмотренных заказчиком. Авторы явно указывают на то, что прототип, созданный в фазе исследования не должен слепо переноситься в реальную систему, вместо этого его нужно использовать как некий исполняемый образец, но ни в коем случае не как формальную спецификацию для итоговой системы.
На этапе разработки прототип приносит пользу, позволяя, во-первых, добавить в систему новые, ранее не предусмотренные функции, во-вторых, облегчает формулирование и анализ пользовательских историй, в-третьих, создает среду для быстрого написания приемочных тестов, на языке, близком к языку предметной области.