[Zope3-dev] Interesting parallels between Zope approach and Naked Objects

[Martijn Faassen]

THoffman@indtech.wa.gov.au wrote:
> Just as an aside, I have recently been reading a book called 
> "Naked Objects" http://www.nakedobjects.org/book/content.html
> which is a about an OpenSource Java framework which 
> bares a striking resemblance to what I believe is the essence 
> of developing systems in Zope/Python (well for me anyway), it raises
> some interesting points about designing "behavioural completeness" and
> the true use of OO..

Thanks for the pointer. Interestingly from what I understand by reading
half of the introduction Zope 2 is actually better at naked objects than
Zope 3. To quote:

"""
[behaviourally-complete objects are a good thing] 
We suggest that even where there is a will to design behaviourally-complete 
objects, there are subtle forces that push back towards data and procedure. 
We have identified five such forces:

    * Business process orientation
    * Task-optimised user interfaces
    * Use-case driven methodologies
    * The Model-View-Controller pattern
    * Component-based software development.

The problem is that not only are all five considered to be best practices,
but they also have the status of sacred cows amongst the software development 
community. We are not suggesting that any of them is itself a bad thing, but
we are suggesting that they hinder good object-oriented design.
"""

Given that in Zope 3 we're heavily employing Model-View-Controller (or
at least the Model/View-Controller separation) and Component-based software
development, and that we use (simple) use cases, we're further away from
naked objects than Zope 2.

That said, Zope 3 is also about exposing more about the object's interface
(and schema) to the public, which lends itself to automatic presentation
of objects without hand-generating a view. From a very cursory check
introspection information like that seems to be how the naked objects framework
avoids growing view code into the objects themselves.

Okay, to quote again:

"""
Instead of allowing the business logic to become scattered across Model, View and Controller objects, find a way to make the View and Controller roles generic, so that the developer writes only the Model objects and all user interaction is derived from this automatically.
"""

This is what Jim is currently working on for forms (automatic edit and add
forms from very minimal descriptions of schema etc).

Since you've been reading more than I have, perhaps you can tell us more?

Regards,

Martijn