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

c_cozianu_at_hotmail.com (Costin Cozianu) hunched over a computer, typing feverishly;
thunder crashed, c_cozianu_at_hotmail.com (Costin Cozianu) laughed madly, then wrote:

(I know I'll regret getting involved in a thread which has already Godwinized ...)

>My rather good level of understanding and practical experience in
>Java,
>C++, Object Pascal (Delphi), and my brief studying of Ada 95, Beta,
>Smalltalk, Python, and even Tutorial D, allows me to draw the
>conclusion that they have
>really different object models.
>In the meantime I wasn't able to find a signle instance of a full and
>complete
>theory on the essence of OOP.
>It may be that I'm wrong, but I wait to here your arguments.
>

Programming used to be done more or less like this:

• Grab a hunk of memory
• Encode data into that memory
• Write code which manipulated that data to produce an output

The hunk of memory encoded with data usually represented something which could be described as an 'object'. The code which manipulated the data could be described as 'methods for accessing object', or 'accessor methods'.

Any program did this, and in a well-written program there was a fairly clear definition of the 'object' and it's 'accessors'. In sloppy code, by comparison, just keeping the whole thing cobbled together and running starts to take on a great deal of complexity. You set aside a block of memory early in a long program for some reason, to represent the current state of the display for instance. You manipulate the data close to the time you create it, but then somewhere later in your program while you're doing something else you find it's easier to manipulate the data again in the later section than to re-write the whole earlier section. Pretty soon, program -flow-, and what the code is actually -doing-, starts to get 'crossed-up'. At any point in the program, you've got tasks going every which way and nobody can follow it. Referred to as 'spaghetti code'.

So the real point, IMO, of any object-oriented language is to enforce that clear separation of object and accessors.

Sure there are big differences in how that's -implemented-, but theory and implementation are separate levels.

>
>> >By the way, you don't need to normalize something that you reach through
>> >an alternative database design method and you can prove it is already
>> >normalized.
>>
>> In case you hadn't noticed, I started this thread by noting that the means
>> to achieve a normalized database are non-deterministic. That means there are
>> several paths and several possible solutions to achieve 5NF. I also noted
>> that the means to evaluate normalization are deterministic.
>>
>> Any method or process that leads to a 5NF design can be called
>> normalization. In that sense, your above statement boils down to:
>>
>> "By the way, you don't need to normalize something once you have normalized
>> it and you can prove it is already normalized."
>>
>> And your point would be....? A less polite response would be: "Duh!"
>
>Sure, might point is that you can pay a visit to, let's say:
>http://hpdrc.cs.fiu.edu/~hpdrc/WS/semantic/Rishe-92-DDS.html.
>
>And see how somebody can follow a simple method to reach a
>good database design, without worying too much about denormalization,
>because he will have already a fully normalized design.
>
>Unlike what happens if somebody studies "Introduction to Database
>Systems"
>and faces a database design problem.
>

Again though, I think this is mixing the theory level with the implementation level a little.

SQL is a logical language, based on set theory, which describes relations between data sets.

IMO, nobody will ever replace it, because the logic isn't going to change. I think it is possible to -abstract- SQL into other forms of data interaction.

An end-user interface to a database might allow them to simply enter search terms, match those terms to any table containing them, then resolve the relations between the tables internally in order to decide what to extract and present. The user never sees either SQL or the SQL logic being applied.

It would be possible to design a whole database system in a similar vein, in which SQL is never used to define those relations.

BUT those relations still exist. All you'd have accomplished would be to create a different way of defining those same relationships.

Imagine you have two sets, A and B. 'Intersection of A and B' refers to all elements in commmon in both sets.

You would write a 'Sets' program which never uses the words 'Intersection of A and B' but if you want to be able to find the elements in common in both sets then you'll just be finding a different way of saying the same thing.

An object-oriented database system would just be doing the same thing.

I don't think your idea is completely without merit, if you can design a database system which defines each record as an 'object' and uses the object relations to automatically normalize the database, and it works better, great.

But the idea that an 'object-oriented database' is something different from a 'SQL oriented database' doesn't seem to mean much to me.

It just seems to be confusing a level of theory with a level of implementation.

***

To put it another way, however you design your database, wouldn't a SQL query still have the same meaning it ever did in relation to it?

And if it didn't, would it be a usable database?

--
Joe Cosby
http://joecosby.home.mindspring.com
 
      FASTER!
            CHEAPER!
                  BETTER!
 
 
Sig by Kookie Jar 5.98d http://go.to/generalfrenetics/