Re: Mixing OO and DB

From: Tegiri Nenashi <TegiriNenashi_at_gmail.com>
Date: Wed, 13 Feb 2008 11:28:06 -0800 (PST)
Message-ID: <9a8bbbf4-7f2a-41ba-98f4-7b0c40df6551_at_u10g2000prn.googlegroups.com>


On Feb 13, 10:25 am, "Leslie Sanford" <jabberdab..._at_bitemehotmail.com> wrote:
> 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.

Algorithm is a function. It might be convenient to split this function into many, introduce an auxiliary structure that captures intermediatory steps of the algorithm. Bundling that structure with functions is a convenience -- no disagrement there.

> I take advantage of the facilities my programming
> language provides for polymorphism.

In my experience polymorphism ir rare if ever needed. I can't remember when I wrote a loop that traverses a heterogenous list. In rare cases when I did it there was something wrong with the design, so that the code has been refactored and simplified, and plymorphism and abstract classes were gone. The last example, a parser able to process any context-free grammar. Natural design: an abstract class with two implementations: CYK algorithm and Earley. In practice, however, I never being able to perfect Earley to be able to compete with CYK, so Earley just become a dead code.

Likewise, I fail to see a really convincing example in the GUI area. A mosue event is broadcasted to a list of widgets, so that the "right" widget knows how to respond? Excuse me, but spamming all the widgets is pretty inefficient way to deliver a message. In most cases it is pretty clear what widget should respond to a message, and database area has some pretty advanced methods how to select a set of things based upon some criteria.

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

I suggest that abstract classes genesis is a result of poor abstraction and speculative generality. In DSP area there is plenty of concrete classes like Matrices, Vectors -- I fail to see what you gain by making these abstract. Perhaps something more sophisticated like Wavelet may benefit of abstraction, e.g HaarWavelet, DebuchetesWavelet? Well, I can't imagine anybody using HaarWavelet for anything other than textbook example, so the point remains moot. Received on Wed Feb 13 2008 - 20:28:06 CET

Original text of this message