Re: Mixing OO and DB
Date: Wed, 13 Feb 2008 14:47:26 -0400
Message-ID: <47b33b45$0$4053$9a566e8b_at_news.aliant.net>
Leslie Sanford wrote:
> "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.
In other words, objects are variables.
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.
In other words, classes are the data types of variables and "behavior" denotes the operations one can perform on values and variables.
> 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.
I think it makes things crystal clear.
> <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.
Why do you assume data types have a physical location?
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.
Did you see the rough sketch of a circuit simulation I posted a year or so ago written in D ? Received on Wed Feb 13 2008 - 19:47:26 CET