Re: Mixing OO and DB

From: Tegiri Nenashi <TegiriNenashi_at_gmail.com>
Date: Thu, 14 Feb 2008 10:02:11 -0800 (PST)
Message-ID: <2531f10c-508c-4a8b-8dc7-ea3bfe14007c_at_v46g2000hsv.googlegroups.com>


On Feb 14, 7:50 am, Robert Martin <uncle..._at_objectmentor.com> wrote:
> 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.

Ok, here is how to solve this problem right.

  1. Don't take "the program" that produces the report on faith. Maybe it would take you 5 minutes to DYI? If the report in question is database one, then sure you can write a query that extracts the data in less than 5 min! Assuming that it is database report (and your reference to the <tab> tag makes me strongly suspect that), you have all the database bells and wistles to do your job, instead of relying onto some obscure program written by nobody.
  2. Let the report data source be something other than database. Again, you don't want to touch the code written by someone else with a large pole. You'd better write a converter instead. There is a whole science how to process linearly ordered data such as strings: regular expessions, formal grammars, etc. In case of the data (as opposed to program source) the grammars defining the data structure tends to be much smaller, so writing a grammar is not such a challenging task.

I admit that formal grammars and languages never enjoyed the sucess comparable to other branches of the programming industry. Among 1000 professionals you'd be lucky to find a single one comfortable with grammars (although percentage utilizing regexps is much higher!). The fault is entirely of the pioneer computer scientists who left the languages and grammars area underdeveloped. The void has been filled in by the horrors of XML.

Please note that formal grammars are declarative specifications of the data which are serialized as strings of characters. Ideally, the grammar solution should be as clean as the database one. In practice, however, there are silly limitations -- you have to check that your grammar conforms to a specific "vision" of the compiler designer. For example, ANTLR goes only as far as LL(*) and chokes on ambiguous grammars. Contrast this to DBMS world where RDBMS executes the query no matter how badly it is written. Received on Thu Feb 14 2008 - 19:02:11 CET

Original text of this message