Re: Mixing OO and DB

"Robert Martin" <unclebob_at_objectmentor.com> wrote in message news:2008030416323223810-unclebob_at_objectmentorcom...
> On 2008-03-03 06:50:39 -0600, "David Cressey" <cressey73_at_verizon.net>
said:
>
> > In my original perspective, the single thing that ties together all the
> > applications and all the databases that collaborate by sharing data is
just
> > one thing: data. If you understand the data, and you understand the
> > (observable) behavior of each of the applications and each of the
databases,
> > you can understand the system. Otherwise, you can't understand the
system.
>
> First of all, I'd like to thank you for that. It was very well done,
> and I found it educational.
>
> Niklaus Wirth once wrote a book entitled: "Algorithms + Data Structures
> = Programs". I think that title should be taken seriously.
>

Agreed.

> I completely agree that you cannot understand a system unless you
> intimately understand the data. By the same token you cannot
> understand a system unless you intimately understand what it does with
> that data. Data and behavior are perspectives, but not ends in and of
> themselves. You can look at a system from a data point of view, but
> you can't escape the need to understand the required behaviors of that
> system. By the same token you can look at a system from a behavior
> point of view, but you can't escape the need to understand the data.
>
It depends. For centuries, humanity had systems that captured data, and made it available to other people. Systems that automatically transform data are a more recent invention. Even a tool like Napier's bones or like the abacus doesn't transform data automatically. It enables an operator to transform data more expeditiously. Programmable systems are a more recent phenomenon.

All this leads me to claim that data is more fundamental than behavior. Not more valid. Just more fundamental. You can have systems that have data but no behavior. You can't have systems that have behavior but no data. At least not the kind of systems you and I are discussing.

> It seems to me that some folks in these forums think that one point of
> view is more valid than the other. That's absurd. There is no truly
> favored point of view. Both need to be taken very seriously.
>

As I said in my earlier comment, it's a matter of perspective.

> However, when writing application code is often advantageous to take a
> behavioral perspective. By the same token, when designing queries and
> modeling enterprises it helps to take a data point of view.
> --

I have a minor quibble with this. It isn't, AFAIK, the beginning of a major battle.
The design of queries is not where the data centric view acquires its power and its relevance, IMO. It's in the design of data for later query. The design of a query has a lot in common with the writing of application code. One can even say that the query, once written, represents something like code. I hesitate to call a query an algorithm, because algorithm suggests "how" rather than "what". Bob Badour has already stated very concisely why "what" is better than "how" in most situations. If you filter his comments, you probably missed this. Too bad. He said it well.

In terms of practical experience, a lot of times when programmers who were SQL newbies approached me with requests for help designing queries, part of the problem turned out to be rooted in an unfortunate (or at least quirky) design of the tables themselves, and not a deficiency in the programmer's grasp of SQL. The whole question of helping newbies with SQL is worth another discussion. That discussion might hinge of some aspects of the DB versus OO way of looking at the world.

The design of tables calls for a very intimate understanding of the data itself, together with a good grounding of knowledge about data itself. The lack of grounding regarding data is, IMO, one of the principal causes of bad database design over the last 15 years. I am sure, without any direct knowledge, the world of OOP is full of bad OO design examples over the same time frame.

But I digress. If data is more fundamental than behavior, as I claim, then data design has to be treated as more consequential than behavior design. I'm not sure exactly what I mean by "consequential", but "harder to reverse" is part of what I'm driving at. Data design includes database design, but is by no means limited to database design. The message systems by which a bunch of objects interact needs to be designed. I'm calling those messages data (even though I've seen some opposite comments from c.o. regulars). And therefore the design of a message system for an OO system is data design, if you accept my nomenclature.

The best integration of the OO point of view with the data centric point of view I've seen is "Object Oriented Analysis" by Coad and Yourden. A lot of the squabbles between c.d.t. and c.o. would be resolved if people could just read that book or some suitable successor to it. Received on Wed Mar 05 2008 - 15:33:36 CET