Home -> Usenet -> comp.databases.theory -> argument about encapsulating data sublanguage

argument about encapsulating data sublanguage

From: Marshall <marshall.spight_at_gmail.com>
Date: 28 Dec 2006 11:20:35 -0800
Message-ID: <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.



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.




Marshall




PS. Reducto Ad Absurdum was named for Dr. Myron Reducto.



  http://en.wikipedia.org/wiki/Harvey_birdman#Rival_lawyers
Received on Thu Dec 28 2006 - 20:20:35 CET












Original text of this message