Re: argument about encapsulating data sublanguage

"Marshall" <marshall.spight_at_gmail.com> wrote in message news:1167333635.567797.260230_at_a3g2000cwd.googlegroups.com...
> While making pancakes this morning I thought of an argument about
> the idea we hear regularly from comp.object folks about how they want
> to hide SQL and the power of the dbms. This is a reductio ad absurdum
> argument; for this post, the irony dial is turned to 11:
>
> We often and rightly hear about the "impedance mismatch" between
> object-oriented code and other, lesser ways of doing things. The
> Object Masters are always exhorting us to encapsulate cohesive
> modules. But one area of opportunity is sadly neglected, and that
> is the encapsulation of the data sublanguage that is built right in
> to most OOPLs.
>
> Consider that most OOPLs, such as Java, contain a mix of notations.
> Both the modern OO notation "x.f(y)" and the old-fashioned math
> notation "x + y" are supported. But why should we continue to
> use such a low-level way of doing things?
>
> Instead, let us encapsulate this separate math-y code into its
> own module. This lets us take some low-level math formula
> and replace it with a high-level abstract interface.
>
> After I've got some algorithms for my application code, I can
> either use low-level formulas:
>
> double dist = sqrt(dx*dx + dy*dy);
>
> Or I can create a higher-level interface that knows something about
> geometry:
>
> double dist = calcDistance(dx, dy);
>
> Using this technique I can hide my formulas behind a procedure.
> This enables me to use an intention-revealing descriptive name,
> rather than the relatively opaque "sqrt(x^2 + y^2)". Also, should
> my application requirements ever change such that I want to
> calculate distance a different way, I only have to change the
> implementation of calcDistance() in one place.
>

When you hide your formulas behind a procedure, what does the procedure stand for? Does it stand for the hidden formulas, or for the results the hidden formulas yield?

> Best of all, this lets me avoid sprinkling math formulas throughout
> my code. Yuck! That stuff needs to be segregated off in one
> place, so it doesn't gum up the works like so much sand.
>

Some programmers would say the same thing about "all the I/O code", or "all the DBMS specific code" or "all the OS specific code".

>
> Marshall
>
>
> PS. Reducto Ad Absurdum was named for Dr. Myron Reducto.
>
> http://en.wikipedia.org/wiki/Harvey_birdman#Rival_lawyers
>
Received on Fri Dec 29 2006 - 19:40:31 CET