Re: Clean Object Class Design -- What is it?

From: JRStern <JRStern_at_gte.net>
Date: Sat, 21 Jul 2001 23:32:53 GMT
Message-ID: <3b409cfe.13837206_at_news.gte.net>


On Sun, 3 Jun 2001 14:41:22 -0400, "Bob Badour" <bbadour_at_golden.net> wrote:
>It has been suggested in another thread that a clean object class design
>obviates the need for normalization.

Different concerns.

And ignorance.

Object modelling tends to worry about optimizing a handfull of anticipated usages, those supported by method creation at coding time.

Database design worries about making data optimally available for ad-hoc queries.

The two camps seldom are talking about the same language or correctly understanding each others' terms.

>What constitutes a "clean" object class design? How does one achieve the
>goal of "cleanliness"? How does one recognize a "clean" design vs an
>"unclean" design? Are the steps for achieving a "clean" design documented
>anywhere? Can we deterministically determine whether a given design is
>"clean" ?

Again, most object discussion center around optimizing today's implementation in terms of complexity or execution or whatever. I don't know that there is any way to recognize a clean design, except in contrast to a dirtier one.

One may argue that there are no general guidelines for cleanliness in semantic terms. One judges semantics by context, so you optimize for today's context, so far as you understand it, if indeed those are your guidelines.

I hate what most developers today see as "clean" designs.

I want to "decorate" a system with internal checks, maintenance functions, at least a little redundancy for easier maintenance and anticipated future requirements, and such. None of these things, desireable tho they may be, are optimal for a given function, and most developers today are proud to leave out all such things.

Also, a great deal of talk about "clean" designs is by people who know zilch about relational database theory and practice.

I greatly prefer that the data come from a normalized database. The objects can draw from complex queries. Let the server do a little work, for gosh sakes! It pays off in the end.

Where the database isn't normalized in the initial design, be assured, significant system enhancement downstream will result from later normalization.

Joshua Stern
JRStern_at_gte.net Received on Sun Jul 22 2001 - 01:32:53 CEST

Original text of this message