Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

Marshall wrote:

> Sure it's an example of change. A really bad, really misguided
> example of change, and one that necessitates some disastrously
> stupid behavior. And one that no one who understood what
> a dbms is would propose.

Oracle is always better than flat files?

The decision to go with Oracle is irreversible?

An Oracle RDBMS that's totally underutilized shouldn't simply be swapped out for flat files?

Write crufty mixed-up code because you "know" some changes won't ever be needed?

Ignore the other benefits (whatever they are) of decoupled code?

And nobody who "understands" a DBMS would ever take one out, even if the situation no longer required one?

> You should really be sure to isolate, in your application, any
> aspects of its architecture that assume an OOPL. An OOPL
> is a method for doing arithmetic, and you ought to be able
> to swap in any other mechanism for doing arithmetic at any
> time, like an abacus or one of those little solar-powered four
> function calculators that they give away at trade shows.

Sounds right.

> Don't use any features like classes or virtual methods.

Why not? If the OOPL is isolated from other things, who cares what the OOPL side does?

We replace the language all the time when we encapsulate something into a module, publish it with some kind of binding, then switch to another language and call it. Your example is not very far-fetched.

However, we hope not to write so much in one OOPL, so cruftily, that we can't pick which modules to convert to another language. That's what encapsulation is for.

-- 
  Phlip
  http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!