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

Hmmm....well, let me get the clickity-clackity engine rev'ed up here...

First, Mr. Badour, let me say that your ad hominem attacks serve no real purpose. Inserting colorful adjectives like, "bullshit", or "blowing smoke out my ass" is a subtle form of subterfuge, in my oh-so-humble opinion. Further, I have been developing software and hardware systems since 1982. I know many programming languages and I've used many database/storage technologies: Relational and object-oriented.

I responded to this thread because I felt that I might be able to answer your question. Evidently, I did not. I apolgize if I wan't articulate enough. But let me sum it up in really plain language here: The OODBMS vendor, whom you questioned, was essentially "correct" in stating that an object-model doesn't need to be "normalized". Why? Because "normalization" is a relational data concept. It doesn't map to the object-oriented world. So, technically, for all intents and purposes, one cannot "normalize" an object model. One can "factor" an object model, but this verb has a slightly different coloring, as it implies both behavioural and data change within a software system.

Now, with this said, and no doubt you'll rip into me here, what I'm sensing from you is a reluctance to accept that an object-oriented view of the world may be substitutable for a procedural/relational view. Are all of these little Java programmers driving you nuts, Bob? Do you feel like your _job_ is in jeopardy? You see: These kinds of statements usually come from someone who is trying to defend their turf. I don't care about your turf. I just tried to answer your question the best I know how. I did this assuming a) You were actually interested in an answer, and b) You recognized that asking about an OODBMS might yield an answer skewed toward object-oriented systems and how they persist data.

As for your comments about programmers and their skill levels: There are good programmers and bad. This will probably always be the case. In think you're being a little naive assuming that relational modeling guarantees that both weak and strong programmers can build the same kinds of systems. This simply doesn't hold up to the light of history. Programming is a _craft_. Either you get a good craftsman or a hack. Some of those craftsman might use relational techniques, others might use object-oriented.

I have no beef against relational databases. They work great with COBOL, RPG, and other procedural languages. But, if I'm writing code in an object-oriented language, then I'll want to use an OODBMS. It simply makes my life easier and improves my productivity, design integrity, and overall performance.

As a final note: Many folks in the IT industry mistakenly assume that electrical, mechanical, chemical, etc. engineers are "prefect". This is not true. Having done a fair amount of EE work I can assure you that it too, is an art. I think that's why it's said as, "This, my friend, is the state of the art".

Regards,
Jeff Panici
Worker Bee Solutions, Inc.

"Bob Badour" <bbadour_at_golden.net> wrote in message news:2k307.3120$oE6.25474158_at_radon.golden.net...
> >First, let me set the stage: The key difference between OO/AD and pure
 data
> >modelling isn't the data at all, it is the behaviour.
>
> How is defining behaviour of object class instance variables any different
> than defining the behaviour of domain instance variables?
>
>
> >Look: While one
> >could argue that a "table" in the relational world is a form of data
> >encapsulation
>
> Good God! I hope not! Relations explicitly do not encapsulate -- they
 expose
> values in tuples.
>
>
> > the stored
> >procedure is a form of encapsulating the "behaviour"
>
> Since "stored procedure" is not a relational concept per se, it has little
> place in a comparison of the relational data model with any other data
> model.
>
>
> >Your opening paragraph states that there might be the possibility of an
> >object model that obviates the need to "normalize".
>
> That was someone else's claim. I was simply trying to verify the claim. I
> think the remainder of the thread and another thread regarding the
> "obviousness" of object designs established that the initial claim was
> simply false.
>
>
> >You see, "normalization" is a data modelling concept
>
> And objects do not represent data? Really?
>
>
> >it has no place
> >in a "clean" object-oriented system.
>
> Let me see: So every user of the system must know how to explicitly avoid
> the consequent update anomalies? Or are you saying that you want the DBMS
 to
> perform incredible feats of unecessary work to enforce integrity
> constraints? Or are you suggesting that the DBMS and its users should
 simply
> ignore integrity for aesthetic reasons?
>
>
> > Responsibility and roles are what one
> >should be designing towards in an object-oriented system
>
> We covered the issue of inheritence vs. role in the thread about the
> so-called obviousness of object designs. I suggest to you that a fully
> normalized database already captures the various roles and relationships.
> The relational model, however, sheds all the various, arbitrary,
> complicating distinctions such as inheritence vs role vs containment.
>
>
> >one-dimensional concept of "data normalization".
>
> Are you truly sufficiently ignorant to believe that "normalization" is
> one-dimensional? Do you even know what normalization is?
>
>
> >Now, one can constrain a system -- where a "clean" object model might
> >live -- with a relational data store, which will cause a deformation of
 that
> >once "clean" object model to begin.
>
> Huh? You are blowing smoke out of your ass. None of the above even has
> meaning.
>
>
> >Because the relational model has
> >only one dimension
>
> Bullshit.
>
>
> >You cannot cram
> >multiple dimensions into fewer.
>
> Since your initial assumptions are patently false, the remainder of the
> argument is fatuous, at best.
>
>
> >Every type of "data" in an object-oriented system is an object.
>
> When you say "an object" do you mean an object class, an object instance,
 an
> object variable or an object value? Your usage is a little imprecise.
>
>
> >As where,
> >in the relational world, it has to be boiled down to a primitive data
 type
> >that is dumb.
>
> Bullshit. A relational domain is exactly the same thing as an object
 class.
> If relational data types are dumb, so are object data types.
>
>
> >Say you have a "zip code". You certainly can't
> >have a ZipCode table that stores only zip-codes for an entire data model.
>
> If one wants and needs a ZipCode table, why couldn't one have one? I would
> propose to you that the USPS probably has a couple of them, at least.
>
>
> >While Codd might admire you for trying, it isn't a practical
> implementation.
>
> A practical implementation of what? A straw man?
>
>
> >So one must "denormalize" and create a primitive and non-descript version
 of
> >the ZipCode in the relational model to aid in system performance.
>
> Huh? Again, you are blowing smoke. The above sentence isn't even
 meaningful.
>
>
> >This leads to: You cannot really compare relational modelling techniques
> >with object-modelling techniques because the two are not even remotely
> >similar.
>
> Really? So, user defined data types (domains) are so fundamentally
 different
> from user defined data types (object classes) that we cannot even begin to
> discuss them? This is absurd.
>
>
> >Mathematics debates aside, there is no similarity.
>
> I don't recall where a mathematics debate entered into the thread. Could
 you
> point one out?
>
>
> >Now, on to your question of, "Can one deterministically determine whether
 a
> >given design is clean?" My answer: No.
>
> Well, this isn't a surprise to me. I think we already established quite
 well
> that nobody has ever defined "clean". From what I have read of the
> references cited by others, the underlying principles are the same for
 both
> relational and object systems. Object systems, due to the unecessary
> complexity, require additional ad-hoc heuristics and recipes, which do not
> add anything in the end.
>
>
> >When you start a project and model data in the relational model, it
> >is moving at a good clip. However, as you denormalize and finialize your
> >model, the train slows down until it eventually stops. Now, you discover
> >that some critical elements are missing!
>
> This is an astounding statement. Do you have any kind of data or reference
> to back it up?
>
>
> >My point is that relational models, to a large degree, require some
 notion
> >of "clean", or done-ness.
>
> All I can say is: It's a good thing that Ron Fagin already proved exactly
> what "done" and "clean" mean for a relational database system, isn't it?
> (5NF)
>
> Date and Darwen have further refined what "done" and "clean" mean by
> requiring a unique predicate for every relation.
>
> Of course, they never would have been able to without the relational
 model's
> mathematical foundation.
>
>
> >As where in the object-oriented world, backed by
> >a transparent _object store_
>
> Transparent in what sense? That it directly exposes the physical layout of
> the stored data to users? Is this an advantage?
>
>
> >there needn't be any arbitrary notion of "clean" or done-ness.
>
> Well, if nobody can define what "clean" is, my initial question is already
> answered. OODB has no deterministic method to guide any part of design. In
 t
> he end, users are at the mercy of the unique mental heuristics of the
> programmer who develops the model. If they have a good, experienced,
 highly
> skilled and productive programmer, they might do okay. However, what
> percentage of programmers out there fall into the above category?
>
> I didn't realise the goal was to make the software crisis worse than it
> already is.
>
>
> >One can
> >continue to "factor" a system to cleanliness over and over again until
 one
> >is satisfied.
>
> So, factoring is different than normalization? How does one know when the
> system is "clean"? What if the programmer actually factors for dirtiness?
>
>
> >However, to get this, you _must_ have the right tools.
>
> What tools? In relational systems, the tools are easy to enumerate.
> Normalization heads the list.
>
>
> >Pairing an object-oriented language with a relational database is not,
 and
 I
> >have a lot of personal experience here, the way to do this.
>
> Really? I've been doing it since 1987. When did you start? How exactly has
> the object-oriented language hindered your effort so far?
>
>
> >I will, however, finish by saying that for most problem domains there is
> >usually a readily apparent, approximately "clean", object model waiting
 in
> >the aether for one to grab and make real.
>
> This all sounds rather nebulous and arbitrary. You have, frankly,
 confirmed
> my suspicions regarding the abject inferiority of OODB systems.
>
> I have paraphrased your answer above to the questions I originally asked
> below:
>
>
> >> It has been suggested in another thread that a clean object class
 design
> >> obviates the need for normalization.
> >>
> >> In relational data modelling, I understand how normalization turns a
 fuzzy
> >> and general conceptual model into a robust logical model. The steps for
> >> achieving normalization are well documented, if not entirely
 deterministic.
> >> The algorithms for recognizing normalized designs are deterministic as
 well.
> >>
> >> What constitutes a "clean" object class design?
>
> Nobody knows.
>
> >>How does one achieve the
> >> goal of "cleanliness"?
>
> Through luck, if at all.
>
> >> How does one recognize a "clean" design vs an
> >> "unclean" design?
>
> One doesn't. One just fiddles with things until one reaches an undefined
> state of "satisfaction".
>
> >> Are the steps for achieving a "clean" design documented
> >> anywhere?
>
> No.
>
> >> Can we deterministically determine whether a given design is "clean" ?
>
> No.
>
> >> How?
>
> Moot question.
>
>
>
Received on Sun Jul 22 2001 - 01:33:13 CEST