Re: Mixing OO and DB
From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Wed, 13 Feb 2008 02:59:47 +0100
Message-ID: <47b24e69$0$85790$e4fe514c_at_news.xs4all.nl>
>
> I have a different understanding.
>
> Objects do not always hide data. Specifically, they pass messages to each
> other in the form of data. 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.
>
> 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.
Date: Wed, 13 Feb 2008 02:59:47 +0100
Message-ID: <47b24e69$0$85790$e4fe514c_at_news.xs4all.nl>
David Cressey wrote:
> Robert Martin wrote:
>> Victor Porton said: >> >>> I know both object oriented programming and DB (SQL). But it seems >>> that these are incompatible. Or may somebody advice how to meddle them >>> together? >> The concepts are orthogonal. Objects are not tables. Tables are not >> objects. The many efforts to try to force tables and objects together >> always cause trouble. Things work better when you recognize the >> benefits of tables, and the benefits of objects, and use each where >> they belong rather than try to force one to use the other. >> >> Tables expose data and have no behavior. Objects hide data and expose >> behavior.
>
> I have a different understanding.
>
> Objects do not always hide data. Specifically, they pass messages to each
> other in the form of data. 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.
>
> 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.
In ISAC (Information Systems Analysis of Change, an originally
Swedish school on Informatics, late 70's) there is a useful technique
called "precedence analysis", with 'Y'-diagrams (like genealogy
trees).
It disregards all computations except as confluence nodes for data.
It goes backwards. Not "where does it go to", but "where does it come
from". Very push-through in situations with mutliple interacting (say