Re: What databases have taught me

From: paul c <toledobythesea_at_oohay.ac>
Date: Wed, 28 Jun 2006 16:12:41 GMT
Message-ID: <ZTxog.103999$Mn5.68840@pd7tw3no>

David Cressey wrote:
> "Robert Martin" <unclebob_at_objectmentor.com> wrote in message
> news:2006062722390616807-unclebob_at_objectmentorcom...
>
>

>> It is not hiearchy that drives OO, it is dependency management.  It is
>> the decoupling of callers from callees through the mechanisms of
>> dynamic polymorhism that is the driving force behind OO design.

>
> This is a significant point. It's worth civil discussion.
>
> From the point of view of databases, the relational model, and its
> commercial implementations (however imperfect), were also about dependency
> management. What we are talking about here is decoupling the writers of
> data from the readers of the same data. Typically, the writers and the
> readers are separated in time, and therefore decoupled in at least one way.
>
> But the mechanisms (if I can call them that) of physical data independence
> and logical data independence allow the decoupling to proceed further than
> it would without those mechanisms. And data independence has been the
> driving force behind data modeling for about 36 years.
>
> The value of data independence tends to be lost on those who use a single
> application, or a suite of applications that share a common object class
> library to write and read data in a database. But all you have to do is try
> to use Crystal Reports on data that was written by a PowerBuilder
> application, and you begin to truly appreciate the value of data
> independence.
>
> I realize the above hasn't said much of anything about dynamic polymorphism,
> but I wanted to lay the foundations for a rational discussion of RM (or
> RDM, as I prefer to call it). A rational discussion of OO and of RM might
> yield insights that the present discussion has not yet yielded.
>
>

Instead of rational discussion I assume one could equally say rational comparison. To compare them, surely one needs to decide which aspects or facets (or in commercial terms, features) of each to talk about. I doubt if 'mechanisms' is the best word to classify such because it suggests implementations which would reduce any discussion to, for example, code.

Surely a comparison would involve discussing the effect of the code, not how the code is put together. In RT, we have have widely agreed upon understanding of the basic operations (join, union, projection and aggregate operators) and how they may be accurately combined in a framework based on the CWA and boolean truth. In OO, the fundamental operations seem to be polymorphism and inheritance, even though the quote above singles out polymorphism as the secret behind the 'driving force' of 'de-coupling'. Surely any discussion should start with something concrete, such as these operations. I would like to know how polymorphism could possibly be compared with, say, join. While polymorphism might allow two values expressed with completely different symbols to be treated as equal and this is certainly useful for comparing domains or implementing aggregate operators, how does it define the logical join of two objects with completely different properties?

(It seems that in the OO world, there is nothing to prevent the implementation of such a join, the result being whatever mysticism the author is prey to at the time. While there are undoubtedly protocols that an OO impl'n is expected to follow, I believe those have nothing to do with defining a predictable result when it is applied to different object instances. I also wonder whether the term 'De-coupling' is jargon when abstraction is really what is being talked about, i.e., two different abstractions are being discussed, one defines what its results will be, the other describes, whatever its results will be, how they are to be obtained.)

p Received on Wed Jun 28 2006 - 11:12:41 CDT