Re: Mixing OO and DB

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

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

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.

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

-- 
Robert C. Martin (Uncle Bob)  | email: unclebob_at_objectmentor.com
Object Mentor Inc.            | blog:  www.butunclebob.com
The Agile Transition Experts  | web:   www.objectmentor.com
800-338-6716                  |