Re: Mixing OO and DB

Robert Martin wrote:
> On 2008-02-13 05:38:32 -0600, "David Cressey" <cressey73_at_verizon.net> said:
>

I'm sorry people, but this is rimming over the pan with gobs of Bullshit. Politeness is off for this one.

> > One of the features of the classical procedural languages is the rigid
> > separation of "program" and "data". In Pascal, for instance, one can create
> > some new Pascal code, in the form of text, manipulating it as though it
> > were data (which it is). But in order to "execute" it, one needs to pass
> > it through the compiler, and from there to the run time system. Once it's
> > "program" it can't be seen as "data" anymore. A program cannot examine
> > itself.
>
> Very nicely put. This is essentially the dinstinction between source
> code and binary code. It is at this boundary where OO has it's power.

It's called a "compiled language". If you have an interpreted language, you have more opportunity for a program to "examine itself" because interpreted languages tend to KEEP the programming structures/ idioms that the code turns into. I don't see how this has anything to do with OO versus procedural. LISP, for example, is highly selfexamining  and was created long before Pascal.

For efficiency, true-compiled languages need to toss higher-level structures, meaning there is less of them to examine at run-time. Java is not a truely compiled language, but a hybrid, I would note. Maybe one could make a hybrid version of Pascal to give it reflexion-like capabilities.

>
> You see, OO is about *source* code. Here's why:
>
> Imagine we have a program that creates a report in text.
>
> Imagine we have a new requirement to *also* produce that report in HTML.
>
> The two reports contain the same data, use the same calculations, and
> are roughly the same tabular format. However, the details of the
> formatting are completely different. One uses tabs and line ends. The
> other uses <table>, <tr>, and <td> tags, etc.
>
> As programmers we have some options.
>
> 1. Copy the report program and change the copy replacing all the tabs
> and newlines with appropriate HTML.
>
> 2. Create a flag and smear "if" statements throughout the report
> program choosing text or html at every output statement.
>
> 3. Completely separate the details for content generation from the
> details of content formatting.
>
> The first is problematic because of the duplicate code. Any change to
> the content of the report, or the general format of the report, must
> now be made in two places.
>
> The second is problematic because it makes a mess of the code, and is
> deeply fragile. It also makes a third format much more difficult.
>
> The third is OO. The technique is simple. All content generation code
> goes in one class. This class makes calls to an object interface that
> has functions for newRow, newCell, etc. There are two implementations
> of the interface. One that emits tabs and line ends, another that
> emits HTML tags.
>
> The *source code* dependencies all point towards the interface. The
> content generation module knows nothing about the two format
> implementations.

There's a 4th possibility that you conveniently skipped. Describe the page as an intermediate data structure (a meta-format), and then each "output type" routine uses that structure to format it as needed.

You guys just don't get table-oriented programming (or at least "data centric", since non-table data structures can do it also if you like navigational structs). My #_at_%^& Goodness!

>
> The benefits are:
>
> 1. We can add new formats without affecting any others.
> 2. We can change content in one place.
> 3. When content changes, the format modules do not need to be
> recompiled, or redeployed; and vice versa.
>
> That last bullet is important.

What about those of us who prefer interpreted invironments? We don't give a flying flip about compilation issues.

And, the approach I described can have an extra module added for a different output type withOUT having to recompile diddly squat because it only has to read an existing data meta-structure or table or file.

In fact, this is more or less how modern device drivers (cough) are often done. For example MS Windows generates a semi-standardized intermediate format, and printerFoo.DLL (or whatever extension they use now) is fed that meta-data structure/format and reshapes it for the device at hand.

That's not OOP, that's data-oriented programming.

Another one of the advantages of an intermediate "meta format" is that it is easier to share across languages and tools. Objects tend to be xenophobic, preferring to be processed ONLY by the lang they were built in. Data-centric info is more sharable.

QED
> Remember that source code is converted
> into binary code through "compilation". Running the compiler can be
> expensive. Deploying binary code to the execution environment can also
> be expensive. OO allows us to make changes to programs without forcing
> us to recompile every module. Well designed OO programs can often be
> changed by recompiling a single module. That recompiled module results
> in a binary file that can be redeployed to the target environment
> without redeploying any other binary modules.
>

Bullshit, as described above.

Anyhow, most instances of variation-on-a-theme that is encountered in custom biz apps does NOT fit the damned device-driver pattern. There is more mix-and-match of features not found in device drivers such that driver-like sub-typing would get messy. SETs (as in set theory) are the best way I've seen to map features to instances. OO is either tree-centric or graph-centric when managing variations-on-a-theme. I find sets conceptually better than graphs. If you have a graphoriented  brain, that is fine, but don't extrapolate that to others. Set's are more "math-able" than graphs, as Dr. Codd found out.

There should be a 10-year moratorium on device-driver-like examples. (Same with shapes and animals.) They are distorting the picture of what real apps need.

>
>
> --
> Robert C. Martin (Uncle Bob)��| email: unclebob_at_objectmentor.com

-T- Received on Thu Feb 14 2008 - 17:31:15 CET