--- In [EMAIL PROTECTED], Luiz Esmiralha
<[EMAIL PROTECTED]> wrote:
> On Mon, 08 Nov 2004 14:25:34 -0000, jhrothjr <[EMAIL PROTECTED]> wrote:
> >
> >
> > --- In [EMAIL PROTECTED], Luiz Esmiralha
> >
> >
> > <[EMAIL PROTECTED]> wrote:
> > > On Mon, 08 Nov 2004 17:37:49 +1300 (NZDT), John Carter
> > > The Naked Objects implementation lets you choose which objects are
> > > "naked" and doesnt expose the internals of an object to the
user, only
> > > the non-private interface. Properties are accessed though
getters and
> > > setters as usual and private methods cannot be called from the
outside
> > > world.
> >
> > It's even a bit more restricted than that.
> > There is a very specific protocol involving
> > naming standards and required method signatures
> > that you have to follow before
> > either an object or any field or method on that
> > object is visible to the outside.
> >
> > While I hate to use the word impossible, I
> > can't think of a way offhand of accidentally
> > exposing something to the outside world that
> > you didn't want exposed.
>
> You are absolutely right. I recall having to use types provided by the
> framework to contain domain objects properties. This creates great
> coupling between the framework and your domain model. This has obvious
> pros and cons, but I think the positive side is dominant.
It really only couples the top layer of your
domain model. I normally think of that as the
application layer, or the Abstract User Interface
layer, so it's perfectly normal to have it coupled
to the Concrete User Interface (aka GUI) layer.
> >
> > > The main idea behind this is permiting direct access to the
underlying
> > > domain model of your application and automatic generation of the
GUI.
> >
> > In the book, they use the notion of "expressive
> > objects", or "behaviorally complete objects".
> > That is, you expose the domain objects
> > that are natural to the way the customer thinks
> > about the domain, and you then make those objects
> > express ***all*** of the properties (fields and
> > actions) that those natural objects can have in
> > the user's conceptual model.
>
> This addresses the Anemic Domain Model anti-pattern as defined by
Martin Fowler?
Took me a moment to find it. I think you
could go either way with it. It's an
Application (or Service, to use Martin
Fowler's terms) Layer, and it has to have
all of the data and behavior that will be
visible to the user. However, these
interfaces can simply be stubs or small
managers, and delegate the actual data
and behavior farther down into the domain
model.
> > > I think its a beautiful idea and I used it to prototype a system
with
> > > great success. I would like to try and plug a custom GUI toolkit
into
> > > it.
> >
> > It's not just a wonderful prototyping tool. I've
> > sometimes thought that all applications should be
> > written that way, with task oriented interfaces
> > bolted on top where there is a clear need.
> >
> I look forward the oportunity to test it in a real distributed
> production environment. Maybe some extension is needed to deploy Naked
> Objects this way?
I believe that the standard production
package is a distributed object system.
If you were using it for a prototype,
you may only have dealt with the development
system, which is local to the developer's
machine.
John Roth
To Post a message, send it to: [EMAIL PROTECTED]
To Unsubscribe, send a blank message to: [EMAIL PROTECTED]
ad-free courtesy of objectmentor.com
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
