[Gnue-dev] Why the Object metaphor? (Was: Object-Relational Mapping?)

[Jason Cater]

For the record, I have been discussing lower-level models and not end-user
models.

However, to move up to the end-user level, I have to ask: Why the
assertion that an object model will be easier to follow than some other
model, such as relational? This assertion is repeatedly made without any
supporting discussion of validity or merit. The only attacks seem to be
toward the more "relational" model as "non-intuitive" (a term I despise,
but will discuss later...)

I agree 100% that an abstraction above the low-level storage is needed.  I
think that's probably a given.  However, in an email on 16 Jan 2003, Neil
asserted:

> I think the goal should be a simple to understand method of 
> modifying the system behavior by non information systems 
> professionals. An object model (implemented well) is easy to 
> explain to someone who is not up on the latest OODB vs relational 
> issues.  One can talk about purchase order objects, sales orders 
> etc.  In the relational world it real easy to lose the abstraction 
> because of the need to normalize data.

Why? When I discuss my relational data storage with my accountants, I
continue to discuss in terms of Purchase Orders, Sales Orders, etc. I
don't discuss in terms of po_master, po_detail, po_addresses, etc. But the
real kicker of that statement is the jump from abstracting into objects,
to discussing why the low-level relational model is too complex for the
end user because of the need to normalize data. That's comparing apples to
oranges. Why can't the underlying relational data be abstracted to a more
user-friendly level, but without the use of objects?

One term I see floating around here alot when objects are discussed is
"intuitive."  I cringe everytime I see this term used.  Are you familiar
with the term "will-o-the-wisp?" It has to do with swamps and a mythical
"Wisp" fairy.  As organic matter in the swamps decay, they give off gases,
such as methane and diphosphane. In a nutshell, diphosphane slowly catches
fire in the swampy areas, turning into translucent balls of glowing light.
Those lost in swamps, who fall for the "will of the Wisp", see these
lights and assume it will lead to civilization. They trek towards the
lights, deeper and deeper into the swamp, and are usually never heard from
again. 

I dare say we may be falling for the "Will-O-The-Intuitive."  This great
desire to have an intuitive model may be the death of us if we don't take
a step back and move beyond the niftiness of being "intuitive."   However
"intuitive" a model or concept appears to be, the user *will* have to
learn it. Why not let them learn something that will benefit them more in
the long run? Sure, we should abstract certain low-level concepts to make
the learning curve as small as possible. My only point is that there
*will* be a learning curve, so merit based on an illusive "intuitiveness"
should be viewed with skeptical eyes. Our goal should be to reduce the
learning curve, not eliminate it. 

Or, as one of my favorite quotes goes:  "The only interfaces intuitive to
a
human are nipples. Everything else is learned."   (Apologies to the
originator of that paraphrased quote, the name of whom I cannot remember.)

Now, on to the object metaphor. At first glance, you are right in that
"Sales Order" makes a nice little "intuitive" object. ("Hey, you are
holding a purchase order in your hand. Notice that it's an object. Well,
in our system, we also have a Sales Order object.") 

The problem with this object representation is that is quickly breaks down
as soon as you move beyond this very basic analogy. An object
representation is heirarchial, and thus very difficult to "query" (for
lack of a better word --pardon my relational tendencies.)  

How does my poor accountant express her desire to list all "Sales
Representatives" (an object I suppose) who have ordered "Widget XXX"
(Supply Item object), have paid for it (Accounts Payable object?), but
have not received it as we had to backorder it (Picking Ticket object??).
She needs this list so she can fire off an email to each one. 

I assert that she cannot without falling back to some complex notation
such as ODMG, or doing a quick procedural program that loops through these
objects.

For that matter, how does my accountant express something as simple as
"List all open Sales Orders." Is the only way for her to do that by using
a Designer wizard, which would hide any looping? Do we have to implement a
method on the SalesOrder object that does this for her?  If so, when she
wants another similar method, does she have to "extend" the Sales Order
object to include her method? In which case, procedural looping would
likely have to happen? Both of these approaches are VERY limiting and
non-untuitive in my opinion. 

Now, to really play devil's advogate.  My accountants DON'T understand
object terminology. If I start discussing Purchase Order objects, I'm
going to get some weird looks. I might even get some snide comments about
being condescending.  

They DO, however, understand our relational backend because it can easily
be expressed in terms of tables. They like tables. Tables are spreadsheets
to them. Primary keys? Hey, those are just control numbers... something
they understand the importance of.  Relationships? I have yet to go into
much detail explaining the definition of a relationship... they seem to
pick up on that fairly quickly since there are a lot of "relationships" in
real life too.  

Sure, the table analogy isn't necessarily intuitive.  It has to be
learned, as with most things in life. However, what I've found is that
they *have* learned the basic concepts of tables after years and years of
doing ledgers or journals. Everything is linked together through control
numbers. Sometimes I even wonder if Codd was started out as an accountant
:) Those trained on spreadsheets even pick it up quicker. The analogy for
them just plain works as they have an existing mindset that is easily
extended to relational theory. 

As a matter of fact, when our head accountant was wanting some very
strange numbers, she would watch over my back as I did quick SQL queries.
After a few times of coming to me, and then watching over my shoulder, she
asked why she couldn't do that? I thought, "why not?" and set her up a
read-only account. She picked up SQL, and the basics of relations, in an
afternoon.  You might say, given her related training, it was "intuitive"
to her. How would she have understood some foreign object paradigm?  I
must add that she is a power-accountant (if there is such a word) but
isn't really that computer savvy. Outside of spreadsheets, she gets lost
quickly. 

Incidentally, I encourage everyone to go back to the links that were
posted by both Leandro Guimarães Faria Corsetti Dutra and I in the
"Object-Relational Mapping" discussion.  This time, read it in terms of
objects as a concept for modeling data, not strictly in terms of specific
implementation issues at the lower level. The concepts (and pitfalls)
still hold true whether you are discussing theory, low-level
implementation, or a model for user abstraction. 


--
Jason Cater
GNU Enterprise