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

Phlip wrote:
> 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?

No, a dbms is only a good choice if one's requirements include data management.

> The decision to go with Oracle is irreversible?

Nope. You can switch out one dbms for another, often fairly easily, due to their being a strong standard. I have seen it done on a number of occasions.

It's probably not as easy at it could be, but it's vastly easier than switching a dbms out for a flat file, assuming the people using the dbms were actually taking advantage of it. If they were just thinking of it as a persistence mechanism, and having to rewrite vast swaths of data management functionality yourself. Concurrency is particularly problematic.

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

If you have a dbms that's totally underutilized, then you have a severe deficiency on the part of the person directing the development. Either he misunderstood the requirements in the first place, or the dbms was needed, and he badly misexecuted the use of it. Neither of these problems comes from architecture choices.

That said, if you're not using a component of a system, swap it out. It doesn't matter what the component is.

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

False dichotomy.

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

I never said that; it is of course false. Strawman.

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

It does? You're joking, right? The above paragraph was entirely ironic; it doesn't contain a single statement I agree with.

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

If OO features have value, then they have value at module boundaries.

This whole "swap out" mania is puzzling to me. Decoupling is a means, not an end in itself, and while it does help, it doesn't help that many things that much.

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

To do that, you have to move to the least-capable version of a module boundary. If you might want to swap out an OOPL for one that isn't OO, you can't have your interfaces be OO. If you write an app entirely in C++, does it make sense to have every module boundary be C-style, functions only, just in case you want to rewrite some module in Pascal? How often do you end up doing that?

I suppose I better understand why you value "narrowness" so much now.

Marshall Received on Sat Jun 03 2006 - 04:33:27 CEST