Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)
Date: Wed, 14 Jun 2006 17:32:08 +0300
"Phlip" <phlipcpp_at_yahoo.com> wrote in message
> 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 ?
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".
> 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 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.
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