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

From: x <>
Date: Wed, 14 Jun 2006 17:32:08 +0300
Message-ID: <e6p6ep$tuv$>

"Phlip" <> wrote in message news:F7Ujg.44456$
> x wrote:
> >> > You don't change the name of a column by the same reason why you
> >> > change a method name in an interface.
> >
> >> I change them each time their ... behavior ... migrates to something
> >> else.

> > Who is "their" ? The names, the columns ?
> > What is this "behavior" ? "Behavior" of data ?

> Let me restate the question. "Data column names are part of the interface
> your database, just as public method names are part of the interface of OO
> classes. If you change their names, you risk the modules that call them.
> when would one ever change their names?"

How often do you change the name of addition ?

> There are two answers. Sometimes you make a mistake, and you must fix it
> improving the name. And sometimes you add features that change the meaning
> of such names.

How can one improve a name ? Make it shorter, prettier ? Name reuse ? I should be using the name 'x' to name everything 'cause I like it ?

> A very simple example: A program with a database goes online with a
> column, and with a public function verifyZipCode(). So then the program is
> popular enough to go overseas, where everyone else calls their ZIP codes
> "Postal Codes". So you must rename both your columns and function names.

Ah, refactoring and code/schema maintenance ... You derive ZIP code class by creating a superclass "Postal Code" or something like that :-)
No need to rename. I would add that you must keep the name.

> > How can a name be a mistake ?
> > Are you talking about name clashes ?

> By "must", we mean if you don't, your program now has cruft. Its GUI says
> "Postal Code", and its internals might still say "ZIP_CODE".

That's absurd. If it is "Postal Code", then it is "Postal Code". If it is "Zip Code", then it is "Zip Code".

>That sounds
> mostly harmless, but when you multiply it by thousands of changes over
> hundreds of engineer-years, the cumulative effect of this "deferred
> maintenance" can ruin the value of a code base.

Not deferred, just incremental. A bit at a time.

> >> Maybe mistakes with databases are harder to fix than other mistakes.
> >
> > Then again maybe they are easier.
> > All logical mistakes are BIG mistakes regardless of the place they
> > Do you suggest that databases are "more logical" than applications ?

> No, I suggest that programmers must constantly perform practices that
> the potential cost of any kind of change.

No change would be the lowest cost then ?

> That means automated tests,
> managing dependencies, constantly cleaning and reviewing, and not living
> with poor design.

Automating changes by using a management system ?

> However, I suspect that some database-oriented developers are more
> to refactor their databases which contain live data, in the field. Because
> databases optimize queries at the expense of all else, a team must write
> extra code to maintain their upgrade paths.

How about backup and restore ?

> > Take this example:
> > min(x,y) if (x<y) return x; else return y;
> >
> > Rename x y and min with anything you like as long as you keep them
> > distinct
> > identifiers and replace all occurences. You will not change anything.
> > Then rename < ( , ) if < return ; else with something else and you
> > screwed
> > it if you also changed the meaning, not just the name.

> If the tests don't break... so what? ;-)

Why the tests would break ? Have you missed the "ALL occurences" and "distinct" ?

How often do you rename "if" , "<" , "+" ? Received on Wed Jun 14 2006 - 16:32:08 CEST

Original text of this message