Re: Mixing OO and DB

From: Robert Martin <>
Date: Mon, 25 Feb 2008 16:33:31 -0600
Message-ID: <200802251633318930-unclebob_at_objectmentorcom>

On 2008-02-25 15:21:58 -0600, topmind <> said:

> Robert Martin wrote:

>> On 2008-02-22 17:41:58 -0600, topmind <> said:
>>>> Actually, I think you have already named some examples.  Using a dummy
>>>> database for testing, for example.  Not that you MUST use OO for these
>>>> things; but often you can, and often it is convenient.
>>> Well, I think that is stretching the definition of OOP a bit far,
>>> almost like saying word-processors are OOP/polymorphic because they
>>> can open any document of a given extension.  That's all the test DB is
>>> like: we simply point the app to a different (test) DB just like a
>>> word-processor or Excel opening a different document.
>> Actually, I think there's a fundamental difference.  In the word
>> processor there is a if/else or switch statment that hands control off
>> to the appropriate file parser.  It goes one way for a .doc and another
>> way for a .rtf.  That's not an OO concept.

> No. I am NOT talking about a different "kind" of database. It uses
> the same brand, just a different data set using the same schema as the
> production system.

I know. And yet it's not a big stretch to different kinds of databases. If the application uses a simple API to access it's data, then that API can be seperated from the application by a polymorphic interface, and dummy databases of a different kind can be substituted in. These databases may act like they contain cannned data; or they might act in ways that simulate errors and faults (that are hard to get a real database to do!)

> By the way, ODBC already does what you say, more or less.

Indeed, it does. ODBC is a polymophic interface that allows you to substitute ODBC compliant engines below it. You *could* use this for creating dummies. But the API approach is a *lot* simpler, and more powerful.

Whether you choose the API approach, or the ODBC approach the concept of substitutability is OO.

>> Now, if we take that one step further, and swap in a dummy database
>> engine, and have the application access it through a polymorphic
>> interface, we have true OO.

> The goal in this particular scenario is to test the app. What you are
> trying to acheive by going OO-crazy here, I don't know.

The goal is to test the app, quickly and easily. I want to create many little simple DB dummies that simulate every possible scenarios as possible, including faults, errors, corruption, and other DB malfunctions.

Robert C. Martin (Uncle Bob)  | email:
Object Mentor Inc.            | blog:
The Agile Transition Experts  | web:
800-338-6716                  |
Received on Mon Feb 25 2008 - 23:33:31 CET

Original text of this message