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

[THoffman@indtech.wa.gov.au]

Hi Martijn

I am by no means an expert (in fact I am not qualified to make any
comment I thin k ;-) in these areas, but Chapter 5 and 6, 
struck a real chord with me
http://www.nakedobjects.org/book/section6.html. 

My initial exposure to OO languages/environments etc, where reading IEEE
journals in the early - mid 80's on Smalltalk, researching OO databases
(like Ontos and Gemstone), and papers comparing delegation vs
inheritance models etc..., and back then I always looked for something
like Zope, where the OO  environment stored code and data as objects.
Then in 2000 I found Zope, which to my mind is one of the closest and
most accessible systems aligned with those ideas. (I also spent some
time using Self, and NeWS/TNT, and then Java before it was Java when I
was at Sun).

What I have seen, is very rarely do systems deal directly with objects
(as I feel they should IMHO ;-) and I do think it comes done to not
being "behaviourally complete" as they outline in this paper. 

AS they also point out in Chapter 6, what appear to be the stalwarts
of system methodolgies definitely have some drawbacks in they way the
tend to make people solve problems.

A big problem I definately see with the way use cases are used/mis-used
is put quite succinctly in my opinion with the following

"The case against use-cases is well summarized by Don Firesmith
[Firesmith1996]: 'Use cases are not object-oriented. Each use case
captures a major functional abstraction that can cause numerous problems
with functional decomposition that object technology was supposed to
avoid . . . . Since they are created . . . . before objects and classes
have been identified, use cases ignore the encapsulation of attributes
and operations into objects.' He goes on to say that a use-case driven
approach results in 'the archetypal subsystem architecture . . . a
single functional control object representing the logic of an individual
use-case and several dumb entity objects controlled by the controller
object . . . Such an architecture typically exhibits poor encapsulation,
excessive coupling, and an inadequate distribution of the intelligence
of the application between the classes'."


and as you pointed out re: MVC the following passage from this chapter
really hi-lights some of things I have witnessed with MVC approach has
been used.

============================begin extract===============================
The motivation for using MVC is the separation of concerns. The argument
is that any given core class of business object will be viewed in many
different ways: on different platforms, in different contexts, and using
different visual representations. Embedding knowledge of all these
different views, as well as the knowledge of how to effect them, into
the business objects themselves would make for bloated objects and heavy
duplication of functionality between objects. Using MVC, the Model
objects have no knowledge of these different views. Dedicated View
objects specify what is to appear in each view, and in what form, and
have the know-how to create the visual display. Controller objects
provide the glue between the two: populating the views with attributes
from the business entity objects, and invoking methods on those objects
in response to events from the user.

This is sound thinking, but it has some negative side effects. Although
it is not the original intent of the MVC approach, the Controller
objects tend to become an explicit representation of business tasks -
especially if the design approach is use-case driven, but also in other
cases. When that happens the role of the Controller objects ceases to be
limited to the technical 'glue' between the user interface and the
business objects. Increasingly they take on the role of task-scripts,
incorporating not only the optimized sequence of activities, but
business rules also - thereby usurping what ought to be responsibilities
of the core business objects. And whilst the View objects cannot be said
to contain business logic in the sense of algorithms, they can
nonetheless end up incorporating a form of business-specific knowledge
in the selection and layout of fields presented for a particular task,
and (sometimes) minor business logic such as maintaining a running total
of entered data.

The net effect is that business-specific knowledge is scattered across
the model, view and controller domains. Any change to the core business
object model will potentially entail changes to a large set of the View
and Controller objects [Holub1999]. Of course this problem is not
restricted to object-oriented design - it applies to most forms of
multi-tiered architectures. Also, there is nothing inherent in MVC that
forces this trend, but the fact that it is common practice suggests that
the pursuit of behaviourally-complete objects requires an explicit means
to counter it.
============================end extract===============================

In my mind, in many cases I believe people are using OO
languages/environments to write procedural code, oh and very complex
models. What I found refreshing with Zope, was it had an intrinsically
more object oriented feel about it (the same goes with python) you  work
with the objects directly, (sure the skinning puts scripts and some
procedures on top of these objects) but fundamentally we interact with
the Zope objects. 

I suppose I would hate to lose that feel with Zope3. However whilst 
I have not yet tried to put something together with Z3, I get the
feeling from this list and the code, that the concerns/issues with
things like MVC are less likely to manifest themselves in this project,
probably due to the Z2 heritage and python as the core technology.

Having said that, one of the "benefits" I see of the Z2 model, where you
can't just whack any old python library in, is you do have to make the
mental switch and create wrapper objects that look more like true
objects to expose the capability to the rest of Zope.

Therefore will the downside with Z3 and the objective of minimising the
effort of getting any old python library into the environment mean that
people don't make the mental transition to thinking about "real
objects"?

Mind you I am probably completely way off base, talking out my a$$
and should be completely ignored and be regarded as an idiot ;-)

See ya

Tim




On Mon, 2002-11-11 at 19:56, Martijn Faassen wrote:
> 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



DISCLAIMER: This email, including any attachments, is intended only for use
by the addressee(s) and may contain confidential and/or personal information
and may also be the subject of legal privilege. Any personal information
contained in this email is not to be used or disclosed for any purpose other
than the purpose for which you have received it. If you are not the intended
recipient, you must not disclose or use the information contained in it. In
this case, please let me know by return email, delete the message
permanently from your system and destroy any copies. Emails and their
attachments may be interfered with, may contain computer viruses or other
defects and may not be successfully replicated on other systems. All
attachments are opened at the recipient's risk.