Re: Mixing OO and DB

From: Leslie Sanford <jabberdabber_at_bitemehotmail.com>
Date: Wed, 13 Feb 2008 12:25:37 -0600
Message-ID: <47b33686$0$6116$4c368faf_at_roadrunner.com>


"David Cressey" wrote:

<snip>

> 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.

I prefer the term algorithm. For me, classes are a place to bundle data with the algorithms that are performed on the data. An instance of a class, an object, preserves the side-effects of running an algorithm on its data. I look at this as the object's state, i.e. objects are state machines. So the "behavior" of an object is whatever results take place when an object runs its data through one of its algorithms. Classes are blueprints for objects. They should be designed in such a way so that whatever algorithms are performed internally by an object of the class maintain the data's invariants. I guess you could call a class a program; it's the combination of data and algorithms.

All the above is my rather simple-minded view of things. It may, or may not, illuminate this discussion.

<snip>

> 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.

I'm not interested in getting rid of data. I need it! :-) But I need a place to put the algorithms that process the data with the data itself. Classes are a convenient place for that. If that's all I were doing, I guess you wouldn't call it OO, but I take advantage of the facilities my programming language provides for polymorphism. This let's me decouple objects from one another so that parts of my applications can vary without effecting other parts. In other words, I can vary the algorithms performed on data in one part of my application without it effecting other areas.

At any rate, my area of programming is DSP. I write synthesizers and effect processors. In my applications I have classes representing "filters," "oscillators," "envelopes," etc. Each of these classes has a set of algorithms that process data. Using polymorphism lets me design these classes in such a way that objects (instances of the classes) can be switched out in a modular way, much like changing the patch cords on the old analog synths. It works for me. Received on Wed Feb 13 2008 - 19:25:37 CET

Original text of this message