Re: Mixing OO and DB

From: David Cressey <cressey73_at_verizon.net>
Date: Wed, 13 Feb 2008 12:07:58 GMT
Message-ID: <y4Bsj.2482$YJ4.231_at_trndny01>


"Robert Martin" <unclebob_at_objectmentor.com> wrote in message news:2008021221010631729-unclebob_at_objectmentorcom...
> On 2008-02-11 16:21:12 -0600, "David Cressey" <cressey73_at_verizon.net>
said:
>
> > Objects do not always hide data. Specifically, they pass messages to
each
> > other in the form of data.
>
> True, but the recipient has no guarantee that the data recieved was
> stored anywhere. Nor can the recipient be sure that the recieved data
> originated in the recieved form. Moreover, the sender expects the
> recipient to do something with the data. All messages connote action
> of some kind.
>

It's the recipient's job to store the data, in general. One fairly important exception: if the sender is a DBMS, the recipient has the guarantee that, if needed, the same value can be conveyed again. One area that confuses some people is who the "recipient" of a database query is. In many contexts, we like to think of the recipient of a query as the client process that partners with the DBMS as a server process. In reality, the receiver is a transaction, not a process. When the recieving process commits a transaction, and starts a new one, the guarantee of isolation from intervening transactions does not span the two transactions. More than one bug is a consequence of flawed thinking in this area.

> > Going further, objects do not "see" the behavior
> > of other objects. What they see is the data, written into messages,
that is
> > the result of behavior. Seeing the result of behavior is not the same
thing
> > as seeing the behavior itself.
>
> Granted, but the dependencies between objects are created by designers
> in pursuit of behaviors. The reason that one object talks to another
> can be found in the behaviors sought by the designers. The reason
> messages are sent, and the reason messages have benavior, is behavior.
>
> >
> > One could do a data centric analysis of an object world, by analyzing
the
> > data passed among the objects in that world. Such an analysis would be
much
> > more like the kind of analysis one makes of a database. Or, perhaps
more
> > likely, analysis of a set of information requirements that is to be
filled
> > by a database not yet designed.
>
> Yes, of course. It's much like the difference bewteen a Mealy state
> machine and a Moore state machine. You can prove that they are
> equivalent forms; but they emphasize different things. Every program
> is a mix of both behavior and data. You can't have one without the
> other. But you *can* use different emphases.
>
>
> --
> Robert C. Martin (Uncle Bob) | email: unclebob_at_objectmentor.com
> Object Mentor Inc. | blog: www.butunclebob.com
> The Agile Transition Experts | web: www.objectmentor.com
> 800-338-6716 |
>
>
>
Received on Wed Feb 13 2008 - 13:07:58 CET

Original text of this message