Re: Objects and Relations

From: David BL <>
Date: 8 Feb 2007 02:25:51 -0800
Message-ID: <>

On Feb 8, 1:04 pm, "dawn" <> wrote:
> On Feb 7, 8:12 pm, "David BL" <> wrote:
> <snip>
> > The semantics of Clone at the problem domain level is generally
> > unambiguous except in its scope (in the sense of has-a relationships
> > to other objects). It always means making a copy of the object such
> > that it has the same attributes but a different identity. This makes
> > sense for a class named EmployeeModel, but not for a class named
> > Employee.
> <snip>
> > The idea that you look at entities (let's just call them nouns if you
> > like) and ask whether they are part of the abstract machine is simple
> > yet important because it neatly explains, without meta-physical mumbo
> > jumbo the non-overlapping difference in scope of RM and OO.
> When I have worked with architects who have prepared models as
> blueprints and they point to their model of a doorway, they call it a
> doorway. They similarly use the terms "room" and "wall." There is no
> confusion at all. I understand they are pointing to a model of a room
> and calling it a room. Similarly with software. There is absolutely
> no reason whatsoever not to name the components of your model after
> that which they are modeling.

Note firstly that you have only provided a metaphor with your architecture blue prints example. An (OO) object by definition encapsulates state, behaviour and identity. All three must be directly associated with the instance in memory. OO is fundamentally about building a machine, not a model of something else. The state, behaviour and identity must all be understood on that basis.

If you were to build a *simulation* (not merely a model) using OO then it would be fair and reasonable to use real world names for the classes. For example a class called "car" may make sense in the scope of the simulation. The identity of a car, its state and its behaviour are all associated with an entity within the abstract machine. For example, change the accelerator position and the car in the simulation accelerates. If you like, take this as a definition of what "simulation" (as distinct from "model") means.

A (data) model by contrast is all about representing knowledge (in the form of attributes and relationships) about entities outside the abstract machine. That is not what OO is intended for, and never was. The programmers who think that OO is suitable for building models should study the RM because it is far better suited for that purpose.

Typically a model only represents partial information about the entities and there is an intention to keep the model in sync with the external entities. There is no intention to think of the model as a machine or even a simulation. It is to represent knowledge.

It is precisely when OO is misused that the semantic lie appears in the names of the classes. Therefore the ugly names represent a nonproblem  and are better regarded as a symptom of the misuse of OO.

> As for the scope of RM and OO, there is obviously an overlapping
> scope. The question is not whether one can persist data using one
> model for the data or another, but what the pros and cons are for
> using either or using some other model. Given a typical software
> application, one could choose to use an OO model, a multivalued model
> (Nelson-Pick model), a relational model, or a codasyl model, for
> example, for the development of this software application. I think
> that shows some overlap in scope, don't you? --dawn

I regard an "OO model" as a contradiction. In that sense I can't see how it can overlap in scope with RM. Received on Thu Feb 08 2007 - 11:25:51 CET

Original text of this message