Re: Object-relational impedence

"David Cressey" wrote:

<snip>

> So far, I've managed in all these discussions to boil the OO vs RM impasse
> down to one single assertion of some of the OO people: that messages are
> not data.
>
> I remain firmly convinced, arguments to the contrary notwithstanding, that
> messages are data, regardless of whether or not messages are used to
> convey
> behavior. And I think that it's the failure to recognize that messages
> are
> data, and that message structuring is data structuring, that has held OO
> aloof from data management for all these years.
>
> In keeping with this thought, I think that an "Object Oriented Database"
> should not store "persistent objects", but rather "persistent messages".
> These messages are directed "To whom it may concern" like a message in a
> bottle. This is quite different from sending a message to a particular
> object. But it's messaging nonetheless.
>
> In order to concretize my thinking, I would have to learn not only OO,
> but
> OOP as well. I'm not sure I have the mental stamina to become procifient
> in
> OOP.
A state machine reaches its current state by receiving messages and performing state transitions in response. If we look at objects as state machines, then your idea of persisting messages could be one way of indirectly persisting objects. To restore an object to its former state, retrieve the messages that were sent to it and resend them. The order of the messages would be important. And they would need to be directed to the right object; I'm not sure about the "To whom it may concern" approach in this regard. This may be an interesting line to follow, but it could turn out to be an extremely tedious way of restoring state machines/objects. You'd need to record all of the messages sent to an object and in the right order.

Perhaps a better way is to ask a state machine to externalize its current state. This could be in the form of a message/data that could be persisted and sent to the object at some point in the future in order to restore it to its former state. The memento design pattern may address this.

David BL's post (which we both praised) talks about what is and is not appropriate to model as objects. Along these lines, I typically find that messages are best represented by David's type A and B categories, i.e. messages should usually be value types. At the implementation level, what this means is that it's rare that I pass an object, type C, to another when sending a message. If I understand David's post, A and B are more easily dealt with in the RM world while objects are not at home there. So... pursuing this line of thought that messages are data may be a good way of finding a bridge between the two. Anyway, just thinking out loud. Received on Mon Mar 17 2008 - 18:56:27 CET