Re: Mixing OO and DB
Date: Tue, 26 Feb 2008 13:28:43 -0800 (PST)
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
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)
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()
> 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
> 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
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