Re: Mixing OO and DB

"Patrick May" <pjm_at_spe.com> wrote in message news:m24pce1izn.fsf_at_spe.com...
> "David Cressey" <cressey73_at_verizon.net> writes:
> > "Robert Martin" <unclebob_at_objectmentor.com> wrote:
> >> 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.
>
> Some messages may contain data, but many do not. Consider this,
> for example:
>
> Thread someThread = new SomeThreadImplementation();
> someThread.run();
>
> Unless you're considering the name of the class and/or the name of the
> method to be data, the message is solely about behavior.
>

On taking a second look there is something of interest to me in the example you gave.

As an aside, I'm not sure what the word "behavior" actually means in the OO world. So, in what follows, I'm going to use the two words "data" and "program", two concepts I think I do understand. What I call "program" may or may not be the same thing that you call "behavior". I don't know, but I'm prepared to learn.

In the first step of your example, what's being conveyed from the expression to the variable is definitely data. The message is, as you said "about behavior". But regardless of what it's about, it's still data. I already pointed this out in a previous reply. As Bob Badour pointed out, it's still data when it's being conveyed by the variable from the first step to the second step. You may choose to think of it as something other than data, but perception is not always reality.

However, in the second step something happens that's of interest to me. The value in the variable is employed as if it were "program". I apologize to the OO crowd if the use of the word "program" is merely extraneous here. The word "behavior" might or might not be what I really mean.

There are only two environments I'm familiar with where "stuff" can be manipulated as though it were "data" in one step, and then evaluated as if it were "program" in a subsequent step. One is machine language and the other is lisp. Both Von Neumann and McCarthy intended this consequence of their respective designs.

One of the features of the classical procedural languages is the rigid separation of "program" and "data". In Pascal, for instance, one can create some new Pascal code, in the form of text, manipulating it as though it were data (which it is). But in order to "execute" it, one needs to pass it through the compiler, and from there to the run time system. Once it's "program" it can't be seen as "data" anymore. A program cannot examine itself.

Now the ability to switch back and forth between manipulating something the way one manipulates data and evaluating something the way one evaluates program is full of power, and full of risk. The people who separated program from data in languages like Pascal were not fools.

But Von Neumann and McCarthy were not fools either.

It may be that, if I am to understand OOP any better than I do, I'm going to have to pursue this thought a little further.

It may also be that, if those of you who know OO but do not know DB want to learn anything, you may have to learn something about data that OO thinking has trained you to overlook. You aren't really going to get rid of data.

What you store in a database is data. Elsewhere in this discussion, people are bloviating to beat the band about the definition of "data". To paraphrase a supreme court justice, "I may not be able to define data, but I know it when I see it." To the extent that OO is about "getting rid of data", the term "OODB" is self-contradictory.

That's as far as I've gotten with this line of thought for now. I'll have more later. Received on Wed Feb 13 2008 - 12:38:32 CET