[#naked-objects-pattern]
= Naked Objects Pattern

:Notice: Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at. http://www.apache.org/licenses/LICENSE-2.0 . Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR  CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
:page-partial:

Apache Causeway implements the naked objects pattern, originally formulated by Richard Pawson.
So who better than Richard to explain the origination of the idea:

__________________________
The Naked Objects pattern arose, at least in part, from my own frustration at the lack of success of the domain-driven approach.
Good examples were hard to find -- as they are still.

A common complaint from _DDD_ practitioners was that it was hard to gain enough commitment from business stakeholders, or even to engage them at all.
My own experience suggested that it was nearly impossible to engage business managers with UML diagrams.
It was much easier to engage them in rapid prototyping -- where they could see and interact with the results -- but most forms of rapid prototyping concentrate on the presentation layer, often at the expense of the underlying model and certainly at the expense of abstract thinking.

Even if you could engage the business sponsors sufficiently to design a domain model, by the time you'd finished developing the system on top of the domain model, most of its benefits had disappeared.
It's all very well creating an agile domain object model, but if any change to that model also dictates the modification of one or more layers underneath it (dealing with persistence) and multiple layers on top (dealing with presentation), then that agility is practically worthless.

The other concern that gave rise to the birth of Naked Objects was how to make user interfaces of mainstream business systems more "expressive" -- how to make them feel more like using a drawing program or _CAD_ system.
Most business systems are not at all expressive; they treat the user merely as a dumb *process-follower*, rather than as an empowered *problem-solver*.
Even the so-called usability experts had little to say on the subject: try finding the word "empowerment" or any synonym thereof in the index of any book on usability.
Research had demonstrated that the best way to achieve expressiveness was to create an object-oriented user interface (_OOUI_).
In practice, though, __OOUI__s were notoriously hard to develop.

Sometime in the late 1990s, it dawned on me that if the domain model really did represent the "ubiquitous language" of the business and those domain objects were behaviorally rich (that is, business logic is encapsulated as methods on the domain objects rather than in procedural scripts on top of them), then the _UI_ could be nothing more than a reflection of the user interface.
This would solve both of my concerns.
It would make it easier to do domain-driven design, because one could instantly translate evolving domain modeling ideas into a working prototype.
And it would deliver an expressive, object-oriented user interface for free.
Thus was born the idea of Naked Objects.
__________________________

You can learn much more about the pattern in the book, link:http://www.amazon.com/exec/obidos/ISBN=0470844205/[Naked Objects], also freely available to link:http://www.nakedobjects.org/book/[read online].
Richard co-wrote the book with one of Apache Causeway' committers, Robert Matthews, who was in turn the author of the Naked Objects Framework for Java (the original codebase of Apache Causeway).

You might also want to read Richard's link:{attachmentsdir}/core-concepts/Pawson-Naked-Objects-thesis.pdf[PhD on the subject].

== Object Interface Mapping

Another -- more technical -- way to think about the naked objects pattern is as an _object interface mapper_, or `OIM`.
Just as an ORM (such as link:http://datanucleus.org[DataNucleus] or link:http://hibernate.org[Hibernate]) maps domain entities to a database, you can think of the naked objects pattern as representing the concept of mapping domain objects to a user interface.
We sometimes use this idea to explain naked objects to a developer audience.



