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

Your rantings on this subject have gone on for months now. In some regards, I think you've turned this into an intellectual snob fest where people who don't use exactly your specialized technical vocabulary are snubbed rather than being taken seriously. If this is in fact the case, then don't even bother responding.

"Bob Badour" <bbadour_at_golden.net> wrote in message news:ASc07.3686$xd3.27600005_at_radon.golden.net...

> One would want the physical store independent of the logical specification
> in any case. This is a good thing.

Let's start with a naive question. Why?

> Unless you normalize the data, how do you even know whether you are
> enforcing all of the constraints?

One of the basic principles of object-oriented programming is that a class is responsible for ensuring that its internal state is coherent. This statement does not imply any mechanism of achieving that constraint, particularly in the context of persistent data. However, the answer to the above question is that enforcing the constraints is a given in an object-oriented approach. While it may take extra thought and care in the relational world, it is a normal part of doing business in the OO one.

> >These data constraints, however, are
> >encapsulated in the code that is used to access the data.
>
> This is not good. Every application that gets written must then enforce
> exactly the same constraints. This is better handled by the database.

No one said the code couldn't be part of the database. Now you are talking about specific implementations. Is this a theory discussion or a practice one? If the latter, then perhaps you should specify which database(s) you are criticizing.

> The question is: If you do not know what normalization is, or even when to
> look for the more esoteric potential update anomalies, how do you know
> whether your class design will avoid them?

I'm not sure if this is one of the vocabulary snobberies I mentioned at the outset or not. It is my opinion (FWIW) that the major difference between a class diagram and an ER diagram is the capability of abstracting complexity through inheritance. I believe that any well thought object model will already be normalized, because that is the nature of object modelling. It is not necessary to have years of relational theory to create normalized models. It is possible to do a thing and not know someone else's name for the thing.

> Well, I would argue that a class model does not imply a proper schema.
> Certainly, one can automaticaly generate a schema from a class model, but
 I
> do not think the result would be very good. Doing so will tend to bias the
> database toward a single application at the cost of all other potential
 uses
> of the data.

You've made this claim several times. I don't get it. A good model is what I call "physics-based". That is, it centers on the most stable aspects of the problem space. NOT the solution space. Just as the laws of physics don't change often, the most stable part of your problem domain is the perspective to use in modelling.

Sure, I've seen a lot of "single-use" object models. I've also seen "single-use" relational models. That's just a question of quality of modelling, not inherent superiority of one technique over the other.

Can you explain why (apart from slipshod, ignorant modellers) an object-oriented approach is necessarily biased to one application?

> In another thread, we explored what was claimed to be an "obvious" class
> design where "manager" was initially modelled as a sub-type of "employee"
> and "employee" was initially modelled as a sub-type of "person". We
> concluded that, in many applications, it is more appropriate to model both
> "employee" and "manager" as roles of "person".

And the "obvious" class design is wrong. Inheritance is not a solution for all the world's ills. There are those in the OO world who argue that inheritance is usually wrong. I'm a practioner, not a theoritist, but I'd imagine that there are some rules that could be codified for evaluating whether inheritance is appropriate or not. In this case, a little educated analysis is enough (what about the person who is employed by two companies?).

> The distinction between sub-type/super-type and object/role, however, is
> entirely arbitrary. In an enterprise-wide system, you will have
 fundamental
> conflicts among those applications that need the relationships modelled
> through inheritence and those applications that need the relationships
> modelled as roles.

Please define an application that needs relationships modelled through inheritance? Inheritance is not about modelling relationships; it is for abstracting complexity.

You seem intent on a jihad against object databases. I don't know why. Yes, the industry is immature compared to the relational market. No, there is no concerted effort toward standardization.

Can't we all just be friends? Received on Sun Jul 22 2001 - 01:33:17 CEST