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

[Daniel E Baumann]

On Sat, Jan 18, 2003 at 12:17:02PM -0600, Jason Cater wrote:
> 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. 

She can make an OQL query. Or call methods of a certain object via a
UI. That all dependent upon the designer of the application.

> 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.

ODMG is complex how? How is Object Query language any more complex
than our beloved SQL? How are objects anymore complex than relational
terminology?
 
> 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. 

That would be up to the application designer, you would do an OO
analysis, assign responsiblities to certain objects, use well known
design pattern where applicable, etc. Perhaps you should pick up a
good book on OOA/D. This one is excellent: Applying UML and Patterns :
An Introduction to Object-Oriented Analysis and Design and the Unified
Process:
http://search.barnesandnoble.com/textbooks/booksearch/isbnInquiry.asp?userid=32V0H7JFXE&isbn=0130925691&TXT=Y&itm=1

> 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.  

Object terminology is no more complex than relational terminology and
thet are added benefits in using objects; modularity, reusablility,
encapsulation (high cohesion, low coupling), polymorphism (creating
your own types), inheritance, etc. I would suggest studying design
patterns and/or reading the GoF Design Patterns book. I know there are
many here who don't ever use these. In fact, I remember arguing about
using a Singleton for something once in IRC which I still find
rediculous.

> 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.  

There are also many objects in life.
 
> 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. 

Well seeing that she had to be trained to be an accountant and trained
to use the relational model she could also be trained to think in
objects. The she cold make queries based on object properties, the
class of the object, etc. or it could be abstracted from her and she
could just 'click a button'. Do end users really need to learn SQL or
some query language?

> 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. 

Well I am gonna take a look at this article:
http://www.pgro.uk7.net/cjd1s.htm

Anyway, I am not sure what you are trying to accomplish but OOA/D has
its merits. Similarly, the relational model is also great for
certain things.

Dan
-- 
And if cynics ridicule freedom, ridicule community...if ``hard nosed 
realists'' say that profit is the only ideal...just ignore them, and use 
copyleft all the same.
      -- RMS

Was I helpful?  Let others know: 
  http://svcs.affero.net/rm.php?r=chillywilly