--- "Patrick K. O'Brien" <pobrien@...> wrote:
> "Matthew R. Scott" <gldnspud@...> writes:
>
> > On Sun 2003-09-21 11:03, Patrick K. O'Brien wrote:
> > > I came across an interesting book/website/framework:
> > >
> > > http://www.nakedobjects.org/
> >
> > Great find, Patrick!
> >
> > I've read the first several sections of the book and this looks
> > like a compelling way to develop many types of applications.
>
> Be sure to read this criticism to get a balanced view:
>
> The Emperor Has No Clothes: Naked Objects Meet the Interface
> by Larry L. Constantine
>
> http://www.foruse.com/articles/nakedobjects.htm
Closely paraphrased from nakedobjects.org:
> In the naked objects approach writing an application implies
> writing only the domain objects themselves. All functionality
> is implemented as behaviors or methods on those objects the
> objects can be described as being 'behaviorally complete'.
> Domain objects are then presented directly and automatically to
> the user, by means of a completely generic viewing mechanism.
There are two essential ideas here:
(1) behaviorally complete domain objects
(2) completely generic viewing mechanism
I mostly (but enthusiastically) like Idea (1), and I'm not terribly
excited about Idea (2).
By *mostly* liking Idea (1), I mean that I am enthusiastic about
domain objects that are "behaviorally complete", but only up to
where they know how to display themselves. When I think about a
behaviorally complete object, I am thinking of things such as
validation, constraints (defaults, limits, options, rules), logic,
connections, structure and so on. Such objects can be simple,
complex (having many simple elements) or highly complex.
When it comes to knowing how to display itself, however, a highly
complex domain object will of necessity be limited. *Or else* the
domain object will be hugely complicated, and the benefits of a
generic viewing mechanism will have been lost. One might argue that
domain objects should not be so complex. Well sorry, but some
domains are just complicated, and it doesn't do any good to pretend
that they are not. (IMHO, YMMV)
But what if we were to keep domain objects that are behaviorally
complete up to the point of, but not including, knowing how to
display themselves. And then let's say we were to define an object
that knows how to "present" some component of a domain object to
the user interface. This would surely be as easy as putting such
behavior in the component itself, and perhaps easier. Call such an
object a simple "presenter". In addition, we should define an easy
mechanism for putting together simple presenters to make complex
presenters. The complex presenter would not necessary mirror the
complex domain object precisely, but of course the two would likely
be similar in structure. The advantage of this approach is that as
requirements change, the complex presenter could be changed as
needed without (necessarily) changing the complex domain object and
vice versa.
My use of the term "presenter" above gives away my bias toward the
MVP (model-view-presenter) framework. Reading newsgroups I often
see MVP and MVC (model-view-controller) used synonymously or nearly
so, as though they were different terms for the same rough idea.
But here is how I understand the differences. With the MVC
architecture, the model and the view are tightly connected, and the
controller basically handles ui events. With the MVP architecture,
the model and the view are connected *by* the presenter. The
presenter is responsible for manipulating the model as a response
to the users input to the view. And my main point is that a
presenter can be as simple or as complex as needed. Admittedly,
there is a "tight coupling" between the presenter and the model,
and an even tighter dependency between a presenter and its
associated view(s), but this arrangement allows the association
between views and models to be extremely flexible.
Thus I suggest using "naked objects", but make them "presentable".
Regards,
=====
Donnal Walter
Arkansas Children's Hospital
|