Re: Mixing OO and DB

From: topmind <topmind_at_technologist.com>
Date: Tue, 26 Feb 2008 13:28:43 -0800 (PST)
Message-ID: <1bbd1867-29a8-435e-b6db-11844bfd6883_at_e6g2000prf.googlegroups.com>

Robert Martin wrote:
> On 2008-02-25 15:21:58 -0600, topmind <topmind_at_technologist.com> said:
>
> >
> >
> > Robert Martin wrote:
> >> On 2008-02-22 17:41:58 -0600, topmind <topmind_at_technologist.com> 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.

A "simple" API is going to replace a sophisticated and powerful query language? I don't think so.

Even if technically and economically feasible (I doubt it), the result would fit the stereotype OOP bloat example from my webpage:

NORMAL   print(a + b)

BLOATED

  am = new math.ArithmeticManager()
  opA = new math.Operand((float) a)
  opB = new math.Operand((float) b)
  am.addOperand(opA)
  am.addOperand(opB)

  am.operator = new math.operators.Addition()   am.executeMathOperation()
  system.io.output.print(am.mathOperationResult())

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

Not. It's called "indirection" and has been around looooong before OOP. Variables are indirection. Please don't give OO credit for oxygen, now.

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

It's just a matter of changing which DB the "standard DB" points to in the database Include file. Example:

// stdOdbcName = "production_DB";
stdOdbcName = "test_DB"; // comment out for production

One-stop change. No need to build a fat OO infrastructure just for that. You are gold-plating a 1983 Chevy.

>
> --
> Robert C. Martin (Uncle Bob)��| email: unclebob_at_objectmentor.com
> Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com

-T- Received on Tue Feb 26 2008 - 22:28:43 CET