Re: Objects and Relations

From: David BL <davidbl_at_iinet.net.au>
Date: 5 Feb 2007 21:58:02 -0800
Message-ID: <1170741482.080567.142120_at_a34g2000cwb.googlegroups.com>


On Feb 6, 1:35 am, "dawn" <dawnwolth..._at_gmail.com> wrote:
> On Feb 5, 7:25 am, "David BL" <davi..._at_iinet.net.au> wrote:
>
>
>
>
>
> > On Feb 5, 6:40 pm, "JOG" <j..._at_cs.nott.ac.uk> wrote:
>
> > > On Feb 5, 5:09 am, "David BL" <davi..._at_iinet.net.au> wrote:
>
> > > > 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.
>
> > > First, In the outside world we only identify things by the values of
> > > the attributes they exhibit, and not by some omiscient OID.
>
> > I'm not sure I follow. I don't see anything innately wrong or
> > difficult with labelling external entities with unique identifiers. I
> > agree that entities don't generally come already labelled. Is that
> > what you mean?
>
> > > Second the
> > > 'things' and 'its' of which you speak are not absolute -
> > > interpretation of their scope varies from individual to individual,
> > > and their boundaries cross and blur. Trying to 'encapsulate' one is a
> > > fool's errand, as they don't really exist.
>
> > I'm not sure what you mean. Can you give me an example where it
> > matters that the scope of an external entity is subjective?
>
> > > So, Identity does not exist outside observable attributes, and
> > > symbolic entities do nothing but generate query bias at the logical
> > > layer.
>
> > I agree with the query bias but not your reason for it. For example,
> > I see no difficulty in assigning a label to a particular human. To
> > the extent that facts about that human will be recorded in a typical
> > RM application there is no confusion about the scope or boundary of
> > the human.
>
> > For me it is the problem with trying to record all conceivable
> > information about a human in a single data structure that is
> > problematic, and explains why OO has a hard time of it. I don't see
> > how labelling a human in itself has any difficulties. The problem
> > seems to have far more to do with type analysis (ie classifying
> > humans) in order to know what attributes need to be recorded. This
> > is the fool's errand.
>
> I think I am finally catching on to at least one of your points, and
> if I have, then I disagree with it.
>
> OO folks are not confusing OO objects with the entity they are
> modeling. One can model an "entity" many ways, with pros and cons to
> various approaches. We can model an entity logically using sets,
> propositions, functions, graphs, OO objects, etc. The question is not
> "which of these is right" but "which of these is most useful for our
> purpose".
>
> One of the benefits to using something other than RM-as-typically-
> implemented (using the form previously-known-as-1NF, for example) is
> that you do not need to paste (as many) pieces back together in order
> to view or use your model related to a single entity. Also, when you
> do paste the pieces back together in a single view, you end up with
> multiple propositions, with information repeated, when using RM-as-
> typically-implemented. With OO and other models you might otherwise
> have a single proposition that more closely aligns with a proposition
> one might actually state about the modeled entity
>
> Every model is simply a model (a mathematical metaphor), and not the
> actual object being modeled. So, it will fail to capture everything
> about the thing it is modeling. It must capture that which is
> relevant for purposes of the (user and the) software being written.
> There are issues when modeling at the level of one entity, such as
> asymmetry (and resulting query "bias"). There are also benefits to
> modeling so that you have a good model for "one" (See http://www.tincat-group.com/mewsings/2006/03/data-for-every-1.html). These
> can be discussed as trade-offs, pros and cons, but not in the terms
> you have set up, from my perspective.

It is true that an (OO) object can represent a model of an external entity. However, the identity of the object must be associated with the model and not the entity.

A class called Employee in an OO program is sloppy. Instead it should be called EmployeeModel (or better still EmployeeInfo). Furthermore you should be quite happy to have any number of objects that model the same employee. Identity testing only tells you whether you have the same model. Value testing tells you whether the models are equivalent.

In my own OO designs I don't generally need to append "Model" or "info" onto the end of my class names because I am a systems programmer and my emphasis is on building a device not a model. When I write a class called Stack (or String, Image, Button etc) I regard an associated run time instance (ie object) as being the *real thing* (and not a model for something else), in the same fashion that we call a lump of atoms a computer rather than a model of a computer. Received on Tue Feb 06 2007 - 06:58:02 CET

Original text of this message