Re: Mixing OO and DB

From: David Cressey <cressey73_at_verizon.net>
Date: Sun, 10 Feb 2008 06:42:14 GMT
Message-ID: <a1xrj.647$Uq4.236_at_trndny02>


"topmind" <topmind_at_technologist.com> wrote in message news:09e3c5bf-b099-46b1-bfa3-9076ba08b2c1_at_i29g2000prf.googlegroups.com...
>
>
> David Cressey wrote:

> > The fundamental problem in simulations, as I see it, is autonomy. If
each
> > unit in a simulation is not autonomous, the simulation will be
constrained
> > at the system level to behave in ways that do not mimic the systems
being
> > simulated. Objects are largely autonomous, and that is their great
> > utility. Objects are more autonomous than functions and procedures from
the
> > great programming languages of the 1970s because objects carry state.
That
> > is why OOP has displaced structured programming to a large extent.
>
> In name only, actually. Most production code for custom apps is not
> very OOP. It may use a lot of pre-packaged classes, but the code
> itself is mostly procedural in OO clothing.
>

A very analogous problem exists in many SQL databases in the field. At least, the problem existed 7 years ago, and I believe persists to this day. A large number of SQL database designers have only a primitive idea of how the relational data model works, or how to use it wisely. They design databases as if they were designing a network of linked records, just as they would have in the 1970s.

Then they dress their design in relational clothing, and pass it off as relational. As a consequence, what can really be done with a relational system is frequently so completely misrepresented that the unwary form a distorted view of what it's all about.

> >
> > In order for objects to collaborate they have to exchange signals
(data).
> > In order to usefully exchange data, there has to be a common convention
> > regarding both the form and the content of the messages passed between
> > objects. Most of the OO stuff I've seen (which isn't very much)
> > concentrate on bilateral contracts between pairs of objects as to what
the
> > form and content (meaning?) of exchanged messages will be.
> >
> > Most of the best database work concentrates on universal contracts
(although
> > the word "contracted" isn't widely used) governing the entire body of
data
> > stored in a database, and a vast multitude of transactions that
collaborate
> > (going forward in time) that adhere to the single contract or some
subset of
> > it.
> >
> > This looks overly [constraining] to the programmer accustomed to object
> > oriented thinking.
>
> I think part of the problem is that there are not enough "nimble
> RDBMS" or table engines around, with such ideas as dynamic columns and
> dynamic tables. It's like judging OOP by only looking at Java and
> Eiffel instead of Smalltalk and Python.
>

Your idea of "nimble" and my idea of "chaotic" might overlap. We are going to have to watch out for that subthread if we are going to in fact exchange useful views on OO and RDM, and not quickly degenerate into name calling. Received on Sun Feb 10 2008 - 07:42:14 CET

Original text of this message