Re: Objects and Relations

From: David BL <davidbl_at_iinet.net.au>
Date: 4 Feb 2007 21:09:08 -0800
Message-ID: <1170652148.174266.70950_at_l53g2000cwa.googlegroups.com>


On Feb 3, 11:33 pm, "Walt" <wami..._at_verizon.net> wrote:
> "David BL" <davi..._at_iinet.net.au> wrote in message
>
> > Many of the wars between the OO and RM camps end up in side issues,
> > often with unsubstantiated performance or scalability claims or
> > discussions about whether physical independence is good or bad.
>
> > AFAIK these discussions ignore something simple and fundamental, which
> > I will describe in this post.
>
> > I have previously discussed this on comp.object (with mixed results),
> > and I'm interested in feedback from the relational camp.
>
> > Consider a web server. This can be seen at a number of different
> > "levels of abstraction"
>
> > 1. Elementary particles
> > 2. Atoms
> > 3. Molecules
> > 4. Electronic components
> > 5. Digital circuits
> > 6. Computer
> > 7. Executing process
> > 8. Abstract computational machine
> > 9. Web server
>
> > All of these "levels of abstraction" are equally valid. I don't want
> > to get into boring discussions about what's physical versus logical,
>
> I think I get what you're driving at with multiple "levels of abstraction",
> but before I get into the substance of your discussion, I want to react to
> your introduction.
>
> Layers 1 though 4 are too detailed for this discussion, and are a
> distraction. You can collapse them all into one big layer, the "analog
> layer", where digital signals are stored, transmitted, and manipulated
> using the Physics (and maybe Chemistry and Biology) of the underlying
> material world.
>
> The "digital circuits" layer is something many of us know only as "the layer
> below the last one we have studied". It deserves the mention you gave it.
>
> Between "computer" and "executing process", I would insert several layers
> of abstraction. Here are some possibilities, just off the top of my head:
>
> "Operating system" (Unix or Windows, etc.)
> "DBMS" (Oracle, DB2, etc.)
> "virtual machine" (like the Java virtual machine)
> "runtime environment" (different for various languages and for different
> implementations of some languages).
>
> And finally, "application object library". Essentially the "object world"
> in which all the application objects reside. It's not clear to me whether
> this layer is at a lower or higher level of abstraction than the executing
> process.
>
> As I said, this is off the top of my head. I'll probably change my mind
> later

My intention was merely to drive home the point that virtually all our names for "real" objects around us can in fact be regarded as merely abstractions. I have no problem calling a lump of physical matter a "computer" one day and "garbage" the next when it is taken to the rubbish tip. The way we interpret the world has as much to do with our perception as any underlying reality (which might be strings or branes in 10 or 11 spacetime dimensions according to string theorists, but who knows?). I see no problem calling a collection of pixels displayed on a touch screen (together with hardware/software that allows it to function) a real "button".

You may well wonder why I went to the trouble to set this mindset. On comp.object some people argued that the criterion of whether an object represents itself wasn't meaningful because objects always represent something else. For example, an instance in memory may represent a pure mathematical abstraction like a "stack". On its face this is quite true. However if an instance of a class called "stack" indeed behaves like a mathematical stack at a certain level of abstraction (in the abstract computational machine) then there is a sense in which the instance is not pretending to be something else. Contrast this to an Employee instance that claims to be a human. The difference is that an actual human is not a part of the abstract machine. Actual humans are complex, somewhat illogical entities that have no right to be directly confused with objects in a running process.

Objects by definition must represent the proverbial "it". They must be the "real deal". This is what object identity means. To screw that up is to create lies in the program. I'm amazed that so many OO programmers are happy to do this, even when it is pointed out to them.

BTW in the context of this thread, when I say "OO" I'm thinking predominantly about how an instance of a data structure is thought to encapsulate state, behavior and identity. I'm not particularly characterizing OO by the presence of class hierarchies or by the use of polymorphism.

It's my impression that a poor understanding of object identity leads to designs with excessive class hierarchies. For example an Employee class can be specialised in many ways, such as SalariedEmployee, WagedEmployee, SalesEmployee. The fact of the matter is that external entities like humans are often capable of countless behaviors. Humans can be gardeners, psychopaths, circus performers, parents, carnivores, mammals and so on (and often all at once). RM is much better at stating factual information about humans without pretending to actually represent one for real. The information about a given human can and should be spread across lots of relations. Received on Mon Feb 05 2007 - 06:09:08 CET

Original text of this message